Jump to content

Photo

Want to confirm correct kernel upgrade for Dirty Cow


Best Answer Charles@Bodhi, 18 November 2016 - 01:19 PM

Yep, using a pae-kernel should be possible with a pae-capable CPU. But more factors might play a roll in this. I know my old eeepc with the atom cpu has pae, but the motherboard is not suitable to use it so I'm forced to stick with a non-pae kernel. But you can try it, if it does not work you just uninstall the 3.13 kernel and headers to revert back to the 3.2 kernel you have now.

 

Install the patched kernel using terminology:

sudo apt-get install linux-image-extra-3.13.0-100-generic linux-headers-3.13.0-100-generic

Next reboot.

 

Now Ubuntu has a boot-option for this, called forcepae that sets the missing flag.

 

For this you should add -- forcepae after the words quite splash in the grub kernel line. You can edit that line hitting the "e" when the grub screen appears. On a single-OS machine you might need to hold SHIFT at boot.

 

Now you can test the new kernel. Once you know it works you can make that option permanent by changing grub defaults.

 

Enjoy,

Charles

Go to the full post


  • Please log in to reply
11 replies to this topic

#1 penguinator

penguinator

    Member

  • Members
  • 300 posts
  • LocationFunchal

Posted 05 November 2016 - 12:43 AM

I'm still running version 3, Legacy -- just to confirm that's why I'm posting in this forum -- I realize the answer may be different for version 4.

 

Could someone tell me if this is correct -- to get the Dirty Cow patch I should install, from Synaptic:

 

linux-headers-3.13.0-100

 

And if not, please advise of the correct answer.  Or, please direct me to the answer if it's here, but just not in the version 3 forum.

 

Thanks!  :)


Bodhi v3.0.0 / stable - 32 bit, Legacy
ASUS eeePC 4G/701-L, Atheros wireless module | ASUS eeePC 701SD, Realtech wireless module

701L, 701SD - Celeron-M 900Mhz
 




A big thank you to everyone who contributes to Bodhi Linux


#2 Jeff

Jeff

    Lead Developer

  • Developer
  • 12402 posts
  • LocationBloomington, IL

Posted 05 November 2016 - 10:24 AM

You'll need to manually compile a kernel for the time being if you are worried about it. I'll have to grab the latest upstream kernel from Debian and back compile a package for it for the legacy Bodhi.

 

We don't force kernel upgrades on our users though, so folks will still need to manually upgrade after I do that.

 

Probably have time to do that some time next week.



#3 penguinator

penguinator

    Member

  • Members
  • 300 posts
  • LocationFunchal

Posted 05 November 2016 - 05:20 PM

Probably have time to do that some time next week.

 

Thanks for saving me from 'messing up' my Bodhi installation by installing the wrong kernel.  I'll keep checking this thread.  Assuming this will also appear in Synaptic, I trust there will be 'something' in its name to help the user differentiate it from the kernel that's there now?  

 

Ron


Bodhi v3.0.0 / stable - 32 bit, Legacy
ASUS eeePC 4G/701-L, Atheros wireless module | ASUS eeePC 701SD, Realtech wireless module

701L, 701SD - Celeron-M 900Mhz
 


#4 Jeff

Jeff

    Lead Developer

  • Developer
  • 12402 posts
  • LocationBloomington, IL

Posted 05 November 2016 - 07:30 PM

Correct.

#5 penguinator

penguinator

    Member

  • Members
  • 300 posts
  • LocationFunchal

Posted 17 November 2016 - 12:38 PM

...

We don't force kernel upgrades on our users though, so folks will still need to manually upgrade after I do that.

Probably have time to do that some time next week.

Yes, I agree with that long-standing Bodhi policy -- and normally don't touch the kernel so long as everything is working.  

But is this case different?  I thought I should be running a patched kernel, after reading reports such as this:

"To be simple, using this bug some anonymous person can gain full administrative rights and the anonymous person can take over the computer."

 

...  I'll keep checking this thread.  Assuming this will also appear in Synaptic, I trust there will be 'something' in its name to help the user differentiate it from the kernel that's there now?  

Not to worry if you're still working on it, but if it's available through Synaptic, I'll need help to locate it.  If you could give what appears in the 'Name' field, I'm sure I'll find it.

:) Thanks!


Bodhi v3.0.0 / stable - 32 bit, Legacy
ASUS eeePC 4G/701-L, Atheros wireless module | ASUS eeePC 701SD, Realtech wireless module

701L, 701SD - Celeron-M 900Mhz
 


#6 Jeff

Jeff

    Lead Developer

  • Developer
  • 12402 posts
  • LocationBloomington, IL

Posted 17 November 2016 - 03:53 PM

I'm not going to have time to do this any time soon. You should either upgrade to a PAE kernel that is patched for this from the Ubuntu repos or compile / install an updated kernel from the Debian repositories.

 

Realistically this bug is never going to effect most users.



#7 penguinator

penguinator

    Member

  • Members
  • 300 posts
  • LocationFunchal

Posted 18 November 2016 - 12:32 AM

... You should ... upgrade to a PAE kernel that is patched for this from the Ubuntu repos ...

 

There's a past post where non-PAE was 'advised' over PAE for installing Bodhi on my hardware (refer to signature line on my posts).  

 

But, as I read more, I see it may be only the OS installation that fails, because my processor lacks a 'PAE-flag' -- but the PAE-capability is there.  So maybe, upgrading to a PAE-kernel -- once the OS is already installed -- may be possible?

 

With that in mind (and comments or corrections will be appreciated) how about if I go ahead with the PAE-capable kernel?  

? In that case, could someone please confirm the correct kernel by name, as it would appear, in Synaptic?  

Would it, by any chance, be the one I mentioned in the first post of this thread?


Bodhi v3.0.0 / stable - 32 bit, Legacy
ASUS eeePC 4G/701-L, Atheros wireless module | ASUS eeePC 701SD, Realtech wireless module

701L, 701SD - Celeron-M 900Mhz
 


#8 Charles@Bodhi

Charles@Bodhi

    Old Faithful

  • Moderators
  • 4440 posts
  • LocationZeist, The Netherlands

Posted 18 November 2016 - 01:19 PM   Best Answer

Yep, using a pae-kernel should be possible with a pae-capable CPU. But more factors might play a roll in this. I know my old eeepc with the atom cpu has pae, but the motherboard is not suitable to use it so I'm forced to stick with a non-pae kernel. But you can try it, if it does not work you just uninstall the 3.13 kernel and headers to revert back to the 3.2 kernel you have now.

 

Install the patched kernel using terminology:

sudo apt-get install linux-image-extra-3.13.0-100-generic linux-headers-3.13.0-100-generic

Next reboot.

 

Now Ubuntu has a boot-option for this, called forcepae that sets the missing flag.

 

For this you should add -- forcepae after the words quite splash in the grub kernel line. You can edit that line hitting the "e" when the grub screen appears. On a single-OS machine you might need to hold SHIFT at boot.

 

Now you can test the new kernel. Once you know it works you can make that option permanent by changing grub defaults.

 

Enjoy,

Charles


Medion S4216 Ultrabook, 4GB RAM, 1TB HDD, WIN 10 & Bodhi 4.1.0-64 

Asus eeepc 901, 1GB RAM, 12 GB SSD, Bodhi 3.0.0-32-Legacy & Bodhi 4.1.0-32 Legacy


#9 penguinator

penguinator

    Member

  • Members
  • 300 posts
  • LocationFunchal

Posted 19 November 2016 - 10:13 AM

... But you can try it, if it does not work you just uninstall the 3.13 kernel and headers to revert back to the 3.2 kernel you have now.

 

:) Many thanks for directing me to the proper kernel -- the list that appear in Synaptic is quite lengthy and without your advice I had no idea which to choose.

 

I see this bug gets a CVE (from the Common Vulnerability Scoring System) impact rating of 'Severe' and Ubuntu gives it a 'High' priority, for its users (and presumably for Ubuntu derivatives, as well) -- to fix it with a patch.

 

So, if the suggested kernel fails, I'll get back to this thread for more help!


Bodhi v3.0.0 / stable - 32 bit, Legacy
ASUS eeePC 4G/701-L, Atheros wireless module | ASUS eeePC 701SD, Realtech wireless module

701L, 701SD - Celeron-M 900Mhz
 


#10 DaveL60

DaveL60

    Member

  • Members
  • 191 posts
  • LocationEastern USA

Posted 19 November 2016 - 02:27 PM

Steve Gibson covered this pretty well in Security Now! #583 (transcript, search for "COW"; he does spend rather more describing the basics of race conditions than the details of this particular one).  While it's is a high-severity bug, Steve's advice aligns with Jeff's description: it's mostly a concern for those with Internet-facing Linux servers ("anything with an open port"). For an individual user running their machine on a home or work network behind a typical NAT or corporate firewall, it's a relatively small concern. OTOH, if you've got an Internet facing server, getting a patched kernel onto that system should be a very high priority.



#11 penguinator

penguinator

    Member

  • Members
  • 300 posts
  • LocationFunchal

Posted 22 November 2016 - 04:54 PM

:D Did that ever go so smoothly -- after following Charles' directions, as follows:

...

Install the patched kernel using terminology:

sudo apt-get install linux-image-extra-3.13.0-100-generic linux-headers-3.13.0-100-generic

Next reboot.

...

After the 'Next reboot' step, I thought I'd just let the process continue as if I had the old kernel -- and see what happens.

 

It was just as if nothing had changed.  The boot went directly to the password prompt, then to the Desktop -- possibly a little faster than before.  

 

The forcepae boot-option was apparently not needed (unless it was automatically applied?) although I was ready to add it to the kernel line -- had the system had crashed without it.

 

The process was so transparent, I thought it must still be running the old kernel, but uname -r at terminal confirmed the running kernel to be v.3.13.0-100.

 

So far, everything I've tested works, such as the function key shortcuts.  The WiFi seems to reconnect following Sleep with less delay, than with the previous kernel.  I'll leave the old kernel there for a while, to make sure everything else is working.

 

This eliminates the possibility an unfamiliar router (e.g., not my own, perhaps at a public WiFi hotspot) may have a disabled or misconfigured NAT.  I have no idea how likely or unlikely this might be -- I'll leave that to others who are more knowledgeable.

 In any event, no longer a problem, at least not for DirtyCow!

 

:) Thanks, Charles!


Bodhi v3.0.0 / stable - 32 bit, Legacy
ASUS eeePC 4G/701-L, Atheros wireless module | ASUS eeePC 701SD, Realtech wireless module

701L, 701SD - Celeron-M 900Mhz
 


#12 penguinator

penguinator

    Member

  • Members
  • 300 posts
  • LocationFunchal

Posted 27 November 2016 - 02:56 PM

It was just as if nothing had changed.  ...

 

<_< Well, almost.

 

Something about the upgrade interfered with with reloading the package list, but only through Synaptic or Enlightment updater utility.   Doing it in terminal worked fine.

 

Also, Systemback as a scheduled program stopped working.  

 

In an attempt to fix it without loosing the patched kernel, I did a full system restore from a Systemback backup, taken just before the new kernel was loaded.  This of course had no effect on the new kernel.

 

Upon rebooting, Synaptic and the E17 Updater were again fully functional.  I surmise the kernel update had overwritten 'something' in addition to loading a new kernel??

 

Systemback was reconfigured manually as a program to startup automatically, and since it hadn't run in a while, it immediately began backing up as soon as the setting was accepted by the system.

 

In LinuxMint, the patched kernel ran without these side effects.  I have no idea why there was a difference, but it was easy to fix and nothing was lost.


Bodhi v3.0.0 / stable - 32 bit, Legacy
ASUS eeePC 4G/701-L, Atheros wireless module | ASUS eeePC 701SD, Realtech wireless module

701L, 701SD - Celeron-M 900Mhz
 





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users