5 ms·

"But the attempt didn’t work, because the Linux team was careful enough to notice that that this code was in the CVS repository without having gone through th

"But the attempt didn’t work, because the Linux team was careful enough to notice that that this code was in the CVS repository without having gone through the normal approval process. Score one for Linux." Actually, they were just lucky enough that someone wasn't able to break into the main BitKeeper repository. It is highly unlikely that any private organization could withstand a state sponsored intrusion from the likes of the US, Russia, or China. And that's assuming they needed to. They probably already have found bugs that would let them in without going to such lengths. Also take into consideration that just "Linux" by itself is useless, there will be a lot of other 3rd party applications installed on the system with a lot less strict security over their source code. The particular bug in question doesn't actually provide an exploit, it just sets the current UID to 0. An attacker would still need some other method of executing their own code under that ID which would require the ability to create new processes (e.g. the command line), or a method of altering the code of the current process through some other bug. The fact that an accompanying alteration wasn't found that allowed for that is a good hint that there's a lot more problems.

saagarjha 8y ago
Are there any calls that check the UID before performing a privileged operation? It seems to me like this would be exploitable, since modifying a kernel data structure like this is surely not intended.
- mikeash 8y ago
  I think the other commenter is trying to say that this is only a local exploit, and an attacker would also need a remote exploit (or be allowed remote access) to use it.
- marcosdumay 8y ago
  > Are there any calls that check the UID before performing a privileged operation? All of them. that's what the UID is for.
  - saagarjha 8y ago
    That's what I thought–this basically gives you root access. So it's just a privilege escalation, plain and simple.
type0 8y ago
> The particular bug in question doesn't actually provide an exploit, it just sets the current UID to 0. It's not a bug if it was added intentionally. The ability to become root is the master exploit in this case (a so called backdoor), getting the user level access by the means of some other exploit is kids play compared with taking over the whole machine. There are a bunch of known small bugs that are potential vulnerabilities in Linux, but it also what makes it so ubiquitous and practical system that can run on the majority of the Worlds servers. Unless you want Linux to become OpenBSD, that is... Here's a quote[0] from over 10 years ago: > Security people are often the black-and-white kind of people that I can't stand. I think the OpenBSD crowd is a bunch of masturbating monkeys, in that they make such a big deal about concentrating on security to the point where they pretty much admit that nothing else matters to them. [0] https://lkml.org/lkml/2008/7/15/296 https://lkml.org/lkml/2008/7/15/296
wscott 8y ago
disclaimer: I was one of the BitKeeper developers in 2003 > Actually, they were just lucky enough that someone wasn't able to break into the main BitKeeper repository. That is kinda the point of BitKeeper (and yes git as well). The "main" repository is just a convention and everybody has a copy of it. If you changed a line of code in the history then the checksums wouldn't match and this checksum difference would propagate to all following csets. BitKeeper would give an error when talking to the server with this change. This was actually one of our complaints about git. It is entirely too trusting of blobs of data sent from another git repository. Files are stored and indexed by the SHA1 hash, but that hash is not revalidated when files are read again in the future. We could mangle git objects and then git would checkout bad files without complaining. This would even happen for objects sent over the wire. Only the enclosing checksum is validated but the corrupted objects were not detected. A 'git fsck' would notice, but this is really expensive so rarely used. It has been a long time, so git may have improved.

saagarjha 8y ago

Are there any calls that check the UID before performing a privileged operation? It seems to me like this would be exploitable, since modifying a kernel data structure like this is surely not intended.

mikeash 8y ago
I think the other commenter is trying to say that this is only a local exploit, and an attacker would also need a remote exploit (or be allowed remote access) to use it.
marcosdumay 8y ago
> Are there any calls that check the UID before performing a privileged operation? All of them. that's what the UID is for.
- saagarjha 8y ago
  That's what I thought–this basically gives you root access. So it's just a privilege escalation, plain and simple.

type0 8y ago

> The particular bug in question doesn't actually provide an exploit, it just sets the current UID to 0. It's not a bug if it was added intentionally. The ability to become root is the master exploit in this case (a so called backdoor), getting the user level access by the means of some other exploit is kids play compared with taking over the whole machine. There are a bunch of known small bugs that are potential vulnerabilities in Linux, but it also what makes it so ubiquitous and practical system that can run on the majority of the Worlds servers. Unless you want Linux to become OpenBSD, that is... Here's a quote[0] from over 10 years ago: > Security people are often the black-and-white kind of people that I can't stand. I think the OpenBSD crowd is a bunch of masturbating monkeys, in that they make such a big deal about concentrating on security to the point where they pretty much admit that nothing else matters to them. [0] https://lkml.org/lkml/2008/7/15/296 https://lkml.org/lkml/2008/7/15/296

wscott 8y ago

disclaimer: I was one of the BitKeeper developers in 2003 > Actually, they were just lucky enough that someone wasn't able to break into the main BitKeeper repository. That is kinda the point of BitKeeper (and yes git as well). The "main" repository is just a convention and everybody has a copy of it. If you changed a line of code in the history then the checksums wouldn't match and this checksum difference would propagate to all following csets. BitKeeper would give an error when talking to the server with this change. This was actually one of our complaints about git. It is entirely too trusting of blobs of data sent from another git repository. Files are stored and indexed by the SHA1 hash, but that hash is not revalidated when files are read again in the future. We could mangle git objects and then git would checkout bad files without complaining. This would even happen for objects sent over the wire. Only the enclosing checksum is validated but the corrupted objects were not detected. A 'git fsck' would notice, but this is really expensive so rarely used. It has been a long time, so git may have improved.