Serious Linux Kernel Vulnerability Patched (threatpost.com)

← Back to Stories (view on slashdot.org)

Serious Linux Kernel Vulnerability Patched (threatpost.com)

Posted by timothy on Tuesday January 19, 2016 @01:54AM from the those-famous-many-eyes dept.

msm1267 writes: A patch for a critical Linux kernel flaw, present in the code since 2012, is expected to be pushed out today. The vulnerability affects versions 3.8 and higher, said researchers at startup Perception Point who discovered the vulnerability. The flaw also extends to two-thirds of Android devices, the company added. An attacker would require local access to exploit the vulnerability on a Linux server. A malicious mobile app would get the job done on an Android device. The vulnerability is a reference leak that lives in the keyring facility built into the various flavors of Linux. The keyring encrypts and stores login information, encryption keys and certificates, and makes them available to applications. Here's Perception Point's explanation of the problem.

85 comments

Min score:

Reason:

Sort:

Local user to root on server is serious by Anonymous Coward · 2016-01-19 02:02 · Score: 1, Insightful

The summary downplays the threat to Linux servers with how the "local access required" is phrased. The PoC provided successfully escalates privileges from a local user to root. This is a very serious issue with serious remote exploitation risk.
1. Re:Local user to root on server is serious by gweihir · 2016-01-19 03:47 · Score: 1
  
  A local exploit has no "remote exploitation risk" by its very definition. Your statement just shows that you have no clue what you are talking about.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
2. Re:Local user to root on server is serious by Anonymous Coward · 2016-01-19 05:19 · Score: 0
  
  I don't think I see anything in the PoC preventing an attacker from compiling and/or running this remotely via SSH or a shell drop.
3. Re:Local user to root on server is serious by kthreadd · 2016-01-19 06:27 · Score: 2
  
  A local exploit has no "remote exploitation risk" by its very definition. Your statement just shows that you have no clue what you are talking about.
  Except if combined with a remote vulnerability, perhaps in the web app running locally on the server, or your web browser running on your laptop.
4. Re:Local user to root on server is serious by Anonymous Coward · 2016-01-19 06:31 · Score: 0
  
  A local exploit has no "remote exploitation risk" by its very definition. Your statement just shows that you have no clue what you are talking about.
  Why are people on thin ice so often the first to categorically claim that others don't have a clue? Your principle is isolating the issue to such a degree that it has no practical meaning in the real world.. Attacks come as combinations. This vuln most definitely also has scary implications for remote attack risk if not patched.
5. Re:Local user to root on server is serious by gweihir · 2016-01-19 10:55 · Score: 1
  
  If you have a remote vulnerability, then you already have a remote vulnerability. Get at least the basic terminology right!
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
6. Re:Local user to root on server is serious by gweihir · 2016-01-19 10:56 · Score: 1
  
  The OP managed to make the term "local vulnerability" useless. That rather strongly implies he does now know what it means. No thin ice here.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Question by Anonymous Coward · 2016-01-19 02:09 · Score: 1

Why does the kernel need to store login info, certificates, and the like? Just wondering as it seems like that stuff belongs strictly in user context. (As you can see, I don't know much about Linux).
1. Re:Question by Anonymous Coward · 2016-01-19 02:32 · Score: 1
  
  For example for mounting network file systems. Could in theory be done in userspace, but on linux and windows is not.
2. Re:Question by castionsosa · 2016-01-19 02:37 · Score: 4, Informative
  
  One of the biggest things, is ensuring the data isn't swapped to disk in an unencrypted format.
3. Re: Question by Anonymous Coward · 2016-01-19 02:40 · Score: 0
  
  I think it is used by certain file system drivers, like NFS, to store authentication information.
  Since they run in kernel space, it makes sense to store that information in the kernel somewhere, hence the keyring facility.
4. Re:Question by ArsenneLupin · 2016-01-19 02:51 · Score: 5, Informative
  
  Why does the kernel need to store login info, certificates, and the like?
  While the question is legit, it has nothing to do with the bug.
  The bug is a reference counting issue, where an attacker can trick the kernel to release a buffer and reallocate it to another purpose, while the original process still holds a reference to it. That process can then abuse its reference (from the old purpose) to mess with the buffer (in its new purpose) in such a way that it obtains root privileges.
  It just happens that the original purpose was indeed about key management. But the bug would work just the same way if that purpose was something else. And the vulnerability even exists if this kernel feature is not used at all. It is not about disclosure of keys or anything like this.
5. Re:Question by kthreadd · 2016-01-19 06:39 · Score: 1
  
  Yep, this is the case if you're for example using AFS or NFS with Kerberos authentication, which is fairly common in enterprise environments.
6. Re:Question by Anonymous Coward · 2016-01-20 01:02 · Score: 0
  
  The way I see it, every syscall added increases the potential attack surface.
  As there seem to be other ways to prevent swapping of sensitive memory (gpg has been doing that for years) and setting up an encrypted swap is rather trivial if you really have to worry about people stealing your hard drive on the off chance that there might be a key in the swap, it seems to me that storing user keys in kernel memory is a solution looking for a problem.
  Accounting for this bug, the overall impact on security of this feature will be negative for the foreseeable future. It is rather like installing metal bars on a window on the third floor, and forgetting to close your main door after you are done.
Well, let's see how Google fixes this by cerberusss · 2016-01-19 02:16 · Score: 4, Interesting

Well, let's see how Google fixes this... Although Lollipop (5.0) has been out since june 2014, I can still order for example the HTC Desire 310 which comes with Jellybean (4.2).
How are all of these Android versions in the wild going to get fixed?

--
8 of 13 people found this answer helpful. Did you?
1. Re:Well, let's see how Google fixes this by serviscope_minor · 2016-01-19 02:17 · Score: 4, Insightful
  
  How are all of these Android versions in the wild going to get fixed?
  Haha they're not!
  Welcome to the new way of doing things. Updates are for old fuddy duddies.
  
  --
  SJW n. One who posts facts.
2. Re:Well, let's see how Google fixes this by dreamchaser · 2016-01-19 02:21 · Score: 2
  
  They won't, and that's deliberate by the phone manufacturers and carriers. They want you to keep buying new phones every 1-2 years.
3. Re:Well, let's see how Google fixes this by Geordish · 2016-01-19 02:29 · Score: 2
  
  Google will fix this by updating the ASOP with their fix in the latest version. Possibly even a few previous versions too.
  The problem is the handset makers and carriers won't push the updates down to the handsets they support.
4. Re:Well, let's see how Google fixes this by sasparillascott · 2016-01-19 02:44 · Score: 1
  
  Unless you're driving a somewhat recent Nexus...then you'll get an update fairly quickly.
5. Re: Well, let's see how Google fixes this by Anonymous Coward · 2016-01-19 02:52 · Score: 1
  
  No, the problem is that Google doesn't flex its muscles and force manufacturers and carrirers to push the fixes to the end user.
  All Google has to do is to include a little clause in the terms of their agreements with manufacturers that says: must provide base system patches for at least 2 years, or else, no Google play services.
  That means no play store and no Google maps. That kills the device for 99â... of the people.
  They've disallowed the inclusion of play services to a manufacturer before for far more trivial things.
6. Re:Well, let's see how Google fixes this by castionsosa · 2016-01-19 02:55 · Score: 2
  
  I wouldn't be surprised to see this not get fixed on most Android devices. I'd say, other than Nexus devices, the best way to ensure one gets patches is to move to CyanogenMod.
7. Re:Well, let's see how Google fixes this by RabidReindeer · 2016-01-19 03:19 · Score: 1
  
  Unless you're driving a somewhat recent Nexus...then you'll get an update fairly quickly.
  And if you're not, then the recent OS update broke the whole system and they don't intend to ever fix it.
8. Re:Well, let's see how Google fixes this by serviscope_minor · 2016-01-19 03:37 · Score: 4, Insightful
  
  Unless you're driving a somewhat recent Nexus...then you'll get an update fairly quickly.
  I have a Nexus 4. It's still very much functional, but it's been EOL since May 2015, a scant 2.5 years after it was first released. By contrast my 8 year old eee 900 is happily running the latest version of everything.
  I'm typing this from my W510 laptop (at work---yay for slacking) which is now amazingly approaching 6 years old. It works great. It's running a 2 year old version of ubuntu (14.04 LTS) which will continue to be supported for another 3 years. However, I'll almost certainly upgrade to 16.04 and the laptop will keep on trucking (the 16G of RAM has stopped it aging badly) for many years to come.
  The state of mobile phones is beyond pathetic, compared to what we had for PCs.
  
  --
  SJW n. One who posts facts.
9. Re:Well, let's see how Google fixes this by Anonymous Coward · 2016-01-19 03:45 · Score: 0
  
  Didn't the Nexus 4 get a security update in September, the same month that its third successor was officially announced?
10. Re: Well, let's see how Google fixes this by the_humeister · 2016-01-19 03:58 · Score: 2
  
  This vulnerability affects Linux kernel 3.18 and above. Android 4.1 comes with Linux kernel 3.0.31. My HTC One M8 running Marshmellow (Cyanogenmod 13) is still on kernel 3.4.0
11. Re:Well, let's see how Google fixes this by serviscope_minor · 2016-01-19 04:07 · Score: 1
  
  Didn't the Nexus 4 get a security update in September, the same month that its third successor was officially announced?
  Not according to the all-knowing wikipedia, but it might be wrong.
  
  --
  SJW n. One who posts facts.
12. Re:Well, let's see how Google fixes this by poltsy · 2016-01-19 05:22 · Score: 1
  
  HTC Desire 310 kernel version appears to be 3.4.5. There's nothing to fix.
13. Re:Well, let's see how Google fixes this by shawn2772 · 2016-01-19 06:01 · Score: 3, Informative
  
  Well, let's see how Google fixes this... Although Lollipop (5.0) has been out since june 2014, I can still order for example the HTC Desire 310 which comes with Jellybean (4.2).
  How are all of these Android versions in the wild going to get fixed?
  Since the bug didn't appear until kernel version 3.8, Jellybean devices are safe because Jellybean has kernel 3.4.39.
  Also, since Lollipop and Marshmallow have SELinux in enforcing mode, blocking access to the relevant syscalls, the bug is present but not exploitable on Lollipop and Marshmallow devices.
  This means that only KitKat devices (kernel 3.10) both have the bug and don't have SELinux blocking access to it. KitKat currently has about 36% market share.
  Incidentally, this also means that no Nexus devices are vulnerable. All devices newer than Galaxy Nexus have been upgraded to at least Lollipop, and so have SELinux protection. The GNex stopped at Jelly Bean, so doesn't have a vulnerable kernel (though there are other JB vulns).
14. Re:Well, let's see how Google fixes this by shawn2772 · 2016-01-19 06:27 · Score: 1
  
  I have a Nexus 4.
  Your Nexus 4 got Lollipop, which has SELinux turned on, which should block any access to this vulnerability.
15. Re:Well, let's see how Google fixes this by kthreadd · 2016-01-19 06:29 · Score: 1
  
  Most Android kernels have quite a lot of backported features from newer kernels so I wouldn't be sure just by looking at the version number. I've seen another Android system running on 3.4 which was vulnerable for that reason, not sure how many others are affected.
16. Re:Well, let's see how Google fixes this by Teun · 2016-01-19 09:17 · Score: 1
  
  Over here in The Netherlands there is an upcoming court case of the largest Dutch consumer organisation against the largest phone seller Samsung.
  They want the court to force Samsung to offer updates for at least 2 years after the last phone of a model has been available, presently it's at best 2 years since it appeared on the market.
  There is a good chance of winning as EU law stipulates a minimum warranty of 2 years.
  
  Once it has been decided in one EU country and for the largest manufacturer it should enforced for all brands.
  
  --
  "The likes of Facebook and WhatsApp are free to those whose privacy is of zero value."
17. Re:Well, let's see how Google fixes this by Forever+Wondering · 2016-01-19 10:21 · Score: 1
  
  After the stagefright bug, Google implemented a "rapid response" update system (i.e.) older systems could get security fix updates [but not necessarily feature enhancements]. This preserves the market for new devices but allows older ones to remain secure.
  Google rolled this out to its various vendors (e.g. Samsung, Moto, etc.). Several of them have pledged to honor this. Thus, I recently got an OTA [security] update from Samsung for my Galaxy S3 [that was EOL] to fix stagefright.
  There was a bit of NRE to put this in place by Google [and the vendors]. Now, I expect, that it should be fairly easy to publish security updates even for older phones.
  It's in everybody's best interests to do so. Vendors don't lose the market for new phones. They don't lose market share due to EOL security concerns anymore (e.g. people switch to iPhone simply because Apple can/could publish the security updates anytime). What was an Apple advantage is not one anymore.
  
  --
  Like a good neighbor, fsck is there ...
18. Re:Well, let's see how Google fixes this by batkiwi · 2016-01-19 11:49 · Score: 1
  
  From the article:
  "The vulnerability affects any Linux Kernel version 3.8 and higher. SMEP & SMAP will make it difficult to exploit as well as SELinux on android devices. Maybe we’ll talk about tricks to bypass those mitigation in upcoming blogs, anyway the most important thing for now is to patch it as soon as you can."
  SELinux makes it difficult, but they're going to tell you how to get around it once it's fixed.
  SELinux doesn't block access to this vulnerability, it merely makes exploitation more complex.
19. Re:Well, let's see how Google fixes this by antdude · 2016-01-19 15:23 · Score: 2
  
  Get back to work, slacker. ;P
  
  --
  Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
20. Re:Well, let's see how Google fixes this by shawn2772 · 2016-01-20 03:36 · Score: 2
  
  SELinux doesn't block access to this vulnerability, it merely makes exploitation more complex.
  In Lollipop SELinux it does make it impossible. Nothing in the system used these syscalls, so access to them is completely disabled by SELinux. If you can obtain root you can disable SELinux, but if you can obtain root you don't need the vulnerability.
  In Marshmallow there might be some possibility. A couple of system services started using the feature, so the SELinux configuration was partially opened up. We'll see if it turns out that there is some way to exploit it in Marshmallow. I suspect not, but if there is Marshmallow devices are also quite likely to be getting security updates, so most -- if not all -- will be patched very soon.
  KitKat is the vulnerable population. The portion of it that is using 3.10. After digging a bit more, I found that the Nexus KitKat devices were still on 3.4, and that was the configuration Google recommended. Some OEMs switched to 3.10, though. I have no idea what the market share of KitKat w/3.10 is.
21. Re:Well, let's see how Google fixes this by dohzer · 2016-01-21 16:33 · Score: 1
  
  They should fix it by making newer versions run intolerably slow on old devices, forcing people to buy a new phone.
*sigh* Another patch Tuesday by Anonymous Coward · 2016-01-19 02:17 · Score: 1

I don't know if Linux should be held to a higher standard than Windows, but critical vulnerablilities like this seem to be becoming more and more common (or are just being found more since people are actually starting to look for them). Think how many IoT systems are susceptible to this and will never be updated. This is serious business.
1. Re:*sigh* Another patch Tuesday by Viol8 · 2016-01-19 02:24 · Score: 1
  
  "but critical vulnerablilities like this seem to be becoming more and more common"
  Probably a combination of the kernel becoming ever more complex (or more code anyway), and ever more scrutiny.
2. Re:*sigh* Another patch Tuesday by bbelt16ag · 2016-01-19 02:29 · Score: 1
  
  from my perspective i think we need tools that find these serious bugs in millions of lines of code and point them out.. I am thinking AI would work great at this. it can look for similar bugs to what it have been trained to do.. This stuff is getting too complicated for mere mortals to fix and look for. Not even LInus can find every bug.
  
  --
  NEVER NEVER NEVER NEVER NEVER NEVER NEVER NEVER GIVE UP! "No limitations, no boundaries, there is no reason for them."
3. Re:*sigh* Another patch Tuesday by Anonymous Coward · 2016-01-19 02:41 · Score: 0
  
  The kernel keeps growing. It used to double in size every major release (1.0 -> 1.2 -> 2.0 -> 2.2 -> 2.4 -> 2.6), but that metric doesn't hold since they changed the development model. Major releases are a lot smaller, but features are also being added faster (because they can be real world tested after a couple of weeks rather than after a couple of years).
4. Re:*sigh* Another patch Tuesday by TangoMargarine · 2016-01-19 03:04 · Score: 1
  
  Because nobody's thought of code analysis before.
  I'm skeptical trying to design an AI to do it would be any easier or more effective than what we're already doing.
  
  --
  Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
5. Re:*sigh* Another patch Tuesday by DarkOx · 2016-01-19 04:13 · Score: 2
  
  We have those tools, they are called static source code analyzers, they are even very effective at identifying certain classes of bugs, though they won't find everything and the more clever the code is they worse they do as rule. Kernels unfortunately even when not being authorized by *real programers* tend to have some clever code by necessity and for performance reasons.
  
  --
  Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
6. Re:*sigh* Another patch Tuesday by 110010001000 · 2016-01-19 05:34 · Score: 1
  
  LOL. AI. AI doesn't exist, and likely never will exist. You don't need AI to find bugs like this. You just need software tools, which already exist. Unfortunately it doesn't mean they are applied well or cover all cases.
7. Re:*sigh* Another patch Tuesday by dsmatthews9379 · 2016-01-19 14:02 · Score: 1
  
  IoT systems may be running older, smaller kernel versions, but yeah another reason to only buy fully open gear you can patch yourself, if you don't build your IoT gear from scratch. Even then it is a PITA to have to run around and check every device you have each time a serious security flaw is found, but that's life in Nerdsville for you.
Serious Linux Kernel Vulnerability Patched by Anonymous Coward · 2016-01-19 02:19 · Score: 5, Funny

I don't run Serious Linux, so I'm fine.
1. Re:Serious Linux Kernel Vulnerability Patched by Rik+Sweeney · 2016-01-19 02:25 · Score: 2
  
  Serious Linux users are also fine, because the flaw has been fixed :P
  
  --
  Summation 2
2. Re: Serious Linux Kernel Vulnerability Patched by Anonymous Coward · 2016-01-19 05:10 · Score: 0
  
  Why do you insult people like a 12 year old bully.
  I think we found the school bully. My how the tables have turned. All those bullies are drug addicts or incompetent and need us to fix their shit.
Time taken to overflow by John+Allsup · 2016-01-19 02:42 · Score: 2

Out of curiosity, I decided to see how long it would take to overflow. Looping 2^24 times took 7.5 seconds on my laptop, indicating overflowing the 32bit ref would take about 1/2 hour. (That works out at 2.3m syscall's per second.)

--
John_Chalisque
1. Re:Time taken to overflow by Anonymous Coward · 2016-01-19 03:01 · Score: 1
  
  So on a phone, it would take about six hours, drain the entire battery, and probably cause the thing to explode...
Linsux by Anonymous Coward · 2016-01-19 02:44 · Score: 0

Thankfully I run a real OS like Windows 10.
Re:Systemd may offer a way to avoid exploits of th by Anonymous Coward · 2016-01-19 02:45 · Score: 0

1. Install Debian 7. Use it for over a year with no problems at all.
Your to-do list takes a while to get through.
Re:Systemd may offer a way to avoid exploits of th by Anonymous Coward · 2016-01-19 02:48 · Score: 0

I agree with steps 3-6, but in my case. steps 1 and 2 were:
1. Install CentOS 6. Use it for years with no problems at all.
2. Upgrade to CentOS 6 to CentOS 7. Systemd should be installed.
Other than that, the final solution was the same.
If I could go back in time and tell young me to stick with FreeBSD without young me thinking old me is a loon I would.
Re:Systemd may offer a way to avoid exploits of th by Anonymous Coward · 2016-01-19 02:58 · Score: 0

Patience you must have my young padawan.
Typo in version by Simon+Rowe · 2016-01-19 03:03 · Score: 1

It affects 3.18 and later according to http://perception-point.io/201... rather than 3.8.
1. Re:Typo in version by gweihir · 2016-01-19 03:50 · Score: 2
  
  Read again. Their exploit code is against 3.18, but they say that 3.8 and later is affected.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
What about ESXi? by Anonymous Coward · 2016-01-19 03:07 · Score: 1

Since ESXi is based on the Linux kernel, is it also affected? VMWare is TERRIBLE about patches and security updates, so I have to wonder how many months will pass before this is fixed, if it is an issue.
1. Re:What about ESXi? by Anonymous Coward · 2016-01-19 08:24 · Score: 2, Informative
  
  ESXi is NOT based on the Linux kernel.
  It implements some driver api layers through the vmklinux module to allow Linux kernel modules to be ported to ESXi... similar to how ndiswrapper in Linux works to allow you to run windows drivers on Linux. Also ESXi 5.5 moves away from this with "native drivers" like elxnet.
  The other similarity is some open source software is recompiled and included such as busybox.
  IMHO it is closer to BSD then Linux... but it's actually it's own beast.
2. Re:What about ESXi? by Anonymous Coward · 2016-01-19 10:45 · Score: 0
  
  VMWare is TERRIBLE about patches and security updates
  Citation needed.
3. Re:What about ESXi? by ebvwfbw · 2016-01-20 12:49 · Score: 1
  
  Since ESXi is based on the Linux kernel, is it also affected? VMWare is TERRIBLE about patches and security updates, so I have to wonder how many months will pass before this is fixed, if it is an issue.
  AC - you should know what you're talking about. Obviously you have no clue. I've been using it for years and they update all the time. It's easy to patch. I also have the free home version. Same story. Easy to patch. Just because you never bothered to look doesn't mean it's true.
Re: Winblows by Anonymous Coward · 2016-01-19 03:07 · Score: 0

Where there's only a major vulnerability fixed once a week.
A malicious mobile app by QuietLagoon · 2016-01-19 03:08 · Score: 1

The more I learn about the smartphone compute environment, the less I want one.
.
There appears to be no way to reign in the apps.
1. Re:A malicious mobile app by ITRambo · 2016-01-19 05:33 · Score: 1
  
  One way to reign in apps is to not install any app that you aren't familiar with. Malicious apps can cause the issue. Fully vetted apps should be fine. Never side-load.
2. Re:A malicious mobile app by Anonymous Coward · 2016-01-19 05:43 · Score: 0
  
  There appears to be no way to reign in the apps.
  Really? It's "rein in" and originates from the reins used in controlling a horse.
3. Re:A malicious mobile app by Anonymous Coward · 2016-01-19 05:45 · Score: 0
  
  Tell that to tweens who learned from their friend how to root their phone so they can get free Flappy Crush Saga Jumper from this cool site in Russia.
Won't buy a new phone at all unless it updates by PeterM+from+Berkeley · 2016-01-19 04:08 · Score: 1

I won't upgrade on a 2-year schedule--and I also won't buy from a manufacturer that doesn't support their hardware.
So the manufacturers have went from something to nothing from me.
--PM
Is it a 0-day? by Anonymous Coward · 2016-01-19 04:42 · Score: 0

[blockquote]The Perception Point Research team has identified a 0-day local privilege escalation vulnerability in the Linux kernel...[/blockquote][blockquote]While neither us nor the Kernel security team have observed any exploit targeting this vulnerability in the wild, â¦[/blockquote]
Is the exploit a 0-day or not?
Re:Systemd may offer a way to avoid exploits of th by Eunuchswear · 2016-01-19 04:50 · Score: 1

1. Install Debian 7. Use it for over a year with no problems at all.
Well, apart from some problems where NFS didn't start because the sysvinit tried to mount devices before the network was up.

2. Upgrade Debian 7 to Debian 8. Systemd should be installed.
3. Reboot the computer.
4. Observe that something obscure and non-obvious with systemd prevents the system from booting fully. Try in vain to debug the problem, fighting with binary logs the whole time.
Nope, failed at this step. All my machines are booting with systemd.

--
Watch this Heartland Institute video
Google is not your friend by Anonymous Coward · 2016-01-19 06:04 · Score: 0

There appears to be no way to reign in the apps
It's been around 8 years since Google released Android, and after all that time, they still deny Android users the ability to control what apps are allowed to do post-install. If you want to install an app, you have to allow everything that its developer wishes, and your only alternative is not to install it. This is in stark contrast with every normal Linux-based operating system.
Your Android device does not belong to you because you do not control what it does. It belongs to the app developers and to advertisers, and that's exactly how Google wants it because they provide Google with revenue, and you don't. Google is your enemy.
Re:Systemd may offer a way to avoid exploits of th by Anonymous Coward · 2016-01-19 06:26 · Score: 0

Yep. I've had that NFS networking problem as well. Turns out most inits works really badly when you have mire than one network interface and the first one to come up is not the one you need. A lot of them just thinks that networking is up means that at least one network interface is up.
GOTO still considered harmful by johannesg · 2016-01-19 06:29 · Score: 1, Insightful

According to a comment on Phoronix ( http://www.phoronix.com/forums... ), the cause is a goto:
"And the funny thing is? The guilty line is a fucking GOTO. Everyone using this atrocious coding practice should be shot in the head." ("magika")
User "stevenc" adds: "It's a pretty common pattern of trying to emulate Objected Oriented Programming in C. Try to construct one or more 'objects', otherwise fall back to one or more 'destructors' at end of the function. They'd even implemented their own reference counters within the struct (object) and had function pointers (methods); both of which allowed this to be an exploitable bug. In OO languages these are implemented in the language/interpreter/compiler and usually done right. "
Now please contrast the desire to have C++ features without using C++ with this post: http://article.gmane.org/gmane...
At least one "substandard" programmer has a lot of egg on his face right now...
1. Re:GOTO still considered harmful by fche · 2016-01-19 06:49 · Score: 1
  
  "And the funny thing is? The guilty line is a fucking GOTO."
  No; the goto wouldn't have mattered - the missing key_put() could have been put at either location, with or without the goto.
2. Re:GOTO still considered harmful by johannesg · 2016-01-19 07:56 · Score: 1
  
  I hope you do understand that the fact that you _could_ do it right is not an excuse? The goto makes it easy to get an indigestible spagetti mass of code that defies code analysis and leads to this sort of bug being introduced... The problem with the goto is not that it introduces a four-letter word, but that it makes it easy to make precisely this type of mistake.
3. Re:GOTO still considered harmful by fche · 2016-01-19 08:08 · Score: 1
  
  The same bug would have existed without the goto business:
  if (keyring == new->session_keyring) {
  key_put(...)
  mutex_unlcok(...)
  abort_creds(...)
  return 0;
  }
  would have been just as buggy without the key_put(). The goto was neither necessary nor sufficient for this bug.
4. Re:GOTO still considered harmful by Anonymous Coward · 2016-01-19 08:21 · Score: 0
  
  All this nonsense does is show that the Linux kernel should be rewritten in Rust.
5. Re:GOTO still considered harmful by Anonymous Coward · 2016-01-19 08:55 · Score: 1
  
  You dipshit. The use of goto had nothing to do with this. The use of goto's in the kernel, and in other systems programming contexts, has nothing to do with emulating Object Oriented programming. Its good old fashioned exception handling. You either use nested if-thens or goto's. If can fuckup the cleanup code in either case.
  Goto spaghetti comes from going up and down in the control flow. The use of goto's to unwind during an exception is good old fashioned linear programming. If this confuses you, stay out of low level programming.
6. Re:GOTO still considered harmful by andyn · 2016-01-19 11:24 · Score: 3, Informative
  Guess what! it has nothing to do with OOP emulation. All cleanup in a C program has to be done explicitly by the developer, be it coded in object-oriented, functional, imperative or whatever the paradigm-of-the-week is.
  Furthermore, the way kernel devs use goto for cleanup is one of the ways that actually keeps the code simpler and less prone to errors. There are a few alternatives to do cleanup in complex code:
  Don't do error checks. In your average C101 homework it's often assumed that many syscalls cannot fail. Obviously, the absolute minimum required in a real world program is a simple assert that stops the program before it can misbehave. Any real-world program that cannot lose data or crash the whole system such as office programs, databases and kernels obviously cannot do this.
  Do an early return and clean up all data so far. Very error prone as the cleanup code has to be replicated in multiple places.
  if/do-while(0)-break wrapping of code. Easy as long as there is one tier of resources to allocate. Any more and the function becomes arrow code.
  Wrap the constructors and destructors in a macro to emulate RAII. The result is still arrowish, although the cleanup is harder to fail. Not allowed in many projects due to an undeserved loathing of macros.
  Split the code into multiple functions. Now you have to pass around the state in function parameters. Having the code split into multiple functions makes the it more prone to logic errors.
  Use goto to jump to the cleanup section. All relevant code is kept in the same function and the code between alllocations and frees stays flat and concise.
7. Re:GOTO still considered harmful by johannesg · 2016-01-20 03:43 · Score: 1
  
  Do you really go through life starting conversations with "you dipshit"? How many times have you been hit in the face for that yet?
  Oh wait, is that you Linus?
8. Re:GOTO still considered harmful by Anonymous Coward · 2016-01-21 18:26 · Score: 0
  
  The goto makes it easy to get an indigestible spagetti mass of code that defies code analysis
  1 if (x) { goto 2; } else { goto 5; }
  2 ...
  3 ...
  4 ...
  5 ...
  6 ...
  7 ...
  a "goto" is no different than an "if" -- if your "code analysis" (human or automated) cannot handle an "if" it is worthless.
  what do you think an "if/else" is? it is just a "goto" by another name. which is just a JMP.
  re:
  
  It's a pretty common pattern of trying to emulate Objected Oriented Programming in C. Try to construct one or more 'objects', otherwise fall back to one or more 'destructors' at end of the function
  That is half true. Structures are not "emulating oo-programming" -- although they can.
  this "pattern" does not require "emulating oo-programming" and this says more about the person's bias and that they don't know C.
  this type of code is perfectly easy to follow. yes, it can get hairy having to manage things yourself.
  that is not an "OO thing" -- you could just as easily write auto_malloc() that when your program exits
  it goes and "free()s" everything, and save yourself having to "free()" everything.
  kernel code of course probably does not have an "exit" or "exit handler" but there is nothing inherently "OO" about manual creation/deletion of "objects".
  the C definition of "object" is not "OO" per se -- "object" has a more general meaning and more meanings besides OO stuff.
  it also has a "compiled code" meaning -- you link objects together to get a library or executable. or you stick objects together and make an "archive".
  objcopy objdump are gnu binutils utilities.
  bar() {
  unsigned char ret = 0;
  char * foo = NULL
  foo = malloc(6) ....
  if (x) { goto succeed; }
  goto fail;
  cleanup:
  if (foo) { free(foo); }
  return ret;
  fail: ret = 0; goto cleanup;
  succeed: ret = 1; goto cleanup;
9. Re:GOTO still considered harmful by Anonymous Coward · 2016-01-22 04:39 · Score: 0
  
  In C asserts are intended to be used during testing, and removed by defining NDEBUG when going to production.
  That is why you can't rely on asserts to do mandatory error checking.
Make it rain! by emil · 2016-01-19 09:19 · Score: 1

It is a user's great hope, and the carriers' and oems' great dread, that SuperSU is about to find itself installed on a vast new segment of the Android market. Here's hoping!
Re:Systemd may offer a way to avoid exploits of th by ebvwfbw · 2016-01-20 12:47 · Score: 1

6. Install FreeBSD 10. Now the problem is completely fixed.
And replaced by a whole new set of problems. Problems solved long ago under Linux.
Re:Is it a 0-day?(no) by ebvwfbw · 2016-01-20 12:50 · Score: 1

No, there is no active exploit for this right now. It's all in theory.