6 ms·

The Linux Backdoor Attempt of 2003

141 points by sytse 8y ago

ryanlol 8y ago
http://www.phrack.org/issues/64/15.html http://www.phrack.org/issues/64/15.html
- vectorEQ 8y ago
  no no, its NSA, people are incapable. only 3 letter agencies can find da bugz ;D
- sslalready 8y ago
  If memory serves me right the CVS bug was originally discovered and exploited by a member of an infamous file sharing site. After descriptions(?) of that bug were leaked in underground circles, an east European hacker wrote up his own exploit for it. This second exploit was eventually traded for hatorihanzo.c, a kernel exploit, which was also a 0-day at the time. The recipient of the hatorihanzo.c then tried to backdoor the kernel after first owning the CVS server and subsequently getting root on it. The hatorihanzo exploit was left on the kernel.org server, but encrypted with an (at the time) popular ELF encrypting tool. Ironically the author of that same tool was on the forensic team and managed to crack the password, which turned out to be a really lame throwaway password. And that's the story of how two fine 0-days were killed in the blink of an eye. (The other funny kernel.org story is when a Google security researcher found his own name in the master boot record of a misbehaving server.)
  - ChickeNES 8y ago
    >(The other funny kernel.org story is when a Google security researcher found his own name in the master boot record of a misbehaving server.) Do you have a link to this story? I tried googling but couldn't find it
    - sslalready 8y ago
      No.
- jve 8y ago
  Why is that people with brains write l33t like kids and have such dirty names and ascii drawings?
gmiller123456 8y ago
"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
sys_64738 8y ago
The check should be written: if ((options == (__WCLONE|__WALL)) && (0 = current->uid)) retval = -EINVAL; This would cause a compile error on the naughty code.
- eps 8y ago
  ... or you can keep the code readable and just pay attention to the relevant compiler warning.
  - philjohn 8y ago
    Maybe, or have a linter that checks for things like this. But it doesn't really reduce readability IMHO, although if you're not used to seeing it then it may jump out at you as odd.
- philjohn 8y ago
  Also do the same for the options == This is something I do in code when checking, always put the variable after what you're checking for.
- _kst_ 8y ago
  "Yoda conditions" are controversial. (Personally, I hate them.) Some people find conditions with the constant on the left, like `(0 == foo)`, jarring and difficult to read. Other people apparently aren't bothered by them. In my experience, neither group of people will be convinced by the other side's arguments. https://en.wikipedia.org/wiki/Yoda_conditions https://en.wikipedia.org/wiki/Yoda_conditions
  - gerdesj 8y ago
    Personally, I hate them I'm nearly ambivalent on them: I'm no programmer. On the one hand it looks like relying on behaviour that is correct now but may not be so in the future. On the other it is a little extra safety. It looks horrid. Its a nice mini hack. Nahh: Too specific to one small potential source of error. Rely on this sort of nonsense and before you know it you'll be invoking magic. Use a decent IDE that looks out for it if you need reminding about this class of bug.
apenwarr 8y ago
I enjoy the idea that we can feel safe from attackers because we caught an attacker once, that time back in 2003.
- nickpsecurity 8y ago
  Definitely not safe: https://events.linuxfoundation.org/wp-content/uploads/2017/11/Syzbot-and-the-Tale-of-Thousand-Kernel-Bugs-Dmitry-Vyukov-Google.pdf https://events.linuxfoundation.org/wp-content/uploads/2017/1... Far as backdoors, the most common way professionals do it is disguise them as normal bugs/vulnerabilities. They werent saboteurs: just slipped like everyone does. ;)
  - xelxebar 8y ago
    Your comment reminds me of the Underhanded C Contest. Some of the submissions are absolutely dirty, and it goes to show how feasible it is to slip in these kinds if bugs. http://underhanded-c.org/ http://underhanded-c.org/
    - nickpsecurity 8y ago
      That's a nice example of sneaky subversions. Many examples. I do want to emphasize even more that subversions with low consequences will look like most common, vanilla stuff you will see. Most of them won't make UCC since they look too accidental. Article included a common source of problems and subverison opportunities: replacing == with = or other way around. Few would bat an eye when that could just be a finger slip of a hurried programmer. The other part of things is you don't want to just introduce the defect. It's better to meaningfully improve something so the contributors' image stays good despite problems. So, you want to improve it for performance, readability, or something like that. Then, make sure most of your contributions don't introduce problems. A high-quantity, mostly-positive contributor is a much better saboteur since the bad stuff is both (a) tiny portion of contributions and (b) stuff others screw up on. Therefore, it looks like random defects not worth blocking that contributor. The fact that things like Linux kernel have hundreds of vulnerabilities a year isn't helping. The baseline is way worse than any saboteur would be contributing. Such insecure-by-default projects make their job much easier. Hell, they can look pretty skilled only adding a few vulnerabilities to a project with that many.
jwfxpr 8y ago
Published 2013.
qalmakka 8y ago
While I love, loved, and will always love C, it has too many security dangers like these. I know it's not intrinsically its fault, and that you can mitigate lots of issues using better tooling, but many of the issues with C are due either to poor design choices (just look at the state of string.h) or things nobody could foresee decades ago. While being close to metal is of paramount importance for tasks such as writing kernels, we shouldn't be forced to pick between safety and simplicity; I think that C needs a treatment like C++11 has been to C++. Lots of people will stubbornly stick with C89, but a boy can hope, I guess.

141 points by sytse 8y ago

ryanlol 8y ago

http://www.phrack.org/issues/64/15.html http://www.phrack.org/issues/64/15.html

vectorEQ 8y ago
no no, its NSA, people are incapable. only 3 letter agencies can find da bugz ;D
sslalready 8y ago
If memory serves me right the CVS bug was originally discovered and exploited by a member of an infamous file sharing site. After descriptions(?) of that bug were leaked in underground circles, an east European hacker wrote up his own exploit for it. This second exploit was eventually traded for hatorihanzo.c, a kernel exploit, which was also a 0-day at the time. The recipient of the hatorihanzo.c then tried to backdoor the kernel after first owning the CVS server and subsequently getting root on it. The hatorihanzo exploit was left on the kernel.org server, but encrypted with an (at the time) popular ELF encrypting tool. Ironically the author of that same tool was on the forensic team and managed to crack the password, which turned out to be a really lame throwaway password. And that's the story of how two fine 0-days were killed in the blink of an eye. (The other funny kernel.org story is when a Google security researcher found his own name in the master boot record of a misbehaving server.)
- ChickeNES 8y ago
  >(The other funny kernel.org story is when a Google security researcher found his own name in the master boot record of a misbehaving server.) Do you have a link to this story? I tried googling but couldn't find it
  - sslalready 8y ago
    No.
jve 8y ago
Why is that people with brains write l33t like kids and have such dirty names and ascii drawings?

gmiller123456 8y ago

"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

sys_64738 8y ago

The check should be written: if ((options == (__WCLONE|__WALL)) && (0 = current->uid)) retval = -EINVAL; This would cause a compile error on the naughty code.

eps 8y ago
... or you can keep the code readable and just pay attention to the relevant compiler warning.
- philjohn 8y ago
  Maybe, or have a linter that checks for things like this. But it doesn't really reduce readability IMHO, although if you're not used to seeing it then it may jump out at you as odd.
philjohn 8y ago
Also do the same for the options == This is something I do in code when checking, always put the variable after what you're checking for.
_kst_ 8y ago
"Yoda conditions" are controversial. (Personally, I hate them.) Some people find conditions with the constant on the left, like `(0 == foo)`, jarring and difficult to read. Other people apparently aren't bothered by them. In my experience, neither group of people will be convinced by the other side's arguments. https://en.wikipedia.org/wiki/Yoda_conditions https://en.wikipedia.org/wiki/Yoda_conditions
- gerdesj 8y ago
  Personally, I hate them I'm nearly ambivalent on them: I'm no programmer. On the one hand it looks like relying on behaviour that is correct now but may not be so in the future. On the other it is a little extra safety. It looks horrid. Its a nice mini hack. Nahh: Too specific to one small potential source of error. Rely on this sort of nonsense and before you know it you'll be invoking magic. Use a decent IDE that looks out for it if you need reminding about this class of bug.

apenwarr 8y ago

I enjoy the idea that we can feel safe from attackers because we caught an attacker once, that time back in 2003.

nickpsecurity 8y ago
Definitely not safe: https://events.linuxfoundation.org/wp-content/uploads/2017/11/Syzbot-and-the-Tale-of-Thousand-Kernel-Bugs-Dmitry-Vyukov-Google.pdf https://events.linuxfoundation.org/wp-content/uploads/2017/1... Far as backdoors, the most common way professionals do it is disguise them as normal bugs/vulnerabilities. They werent saboteurs: just slipped like everyone does. ;)
- xelxebar 8y ago
  Your comment reminds me of the Underhanded C Contest. Some of the submissions are absolutely dirty, and it goes to show how feasible it is to slip in these kinds if bugs. http://underhanded-c.org/ http://underhanded-c.org/
  - nickpsecurity 8y ago
    That's a nice example of sneaky subversions. Many examples. I do want to emphasize even more that subversions with low consequences will look like most common, vanilla stuff you will see. Most of them won't make UCC since they look too accidental. Article included a common source of problems and subverison opportunities: replacing == with = or other way around. Few would bat an eye when that could just be a finger slip of a hurried programmer. The other part of things is you don't want to just introduce the defect. It's better to meaningfully improve something so the contributors' image stays good despite problems. So, you want to improve it for performance, readability, or something like that. Then, make sure most of your contributions don't introduce problems. A high-quantity, mostly-positive contributor is a much better saboteur since the bad stuff is both (a) tiny portion of contributions and (b) stuff others screw up on. Therefore, it looks like random defects not worth blocking that contributor. The fact that things like Linux kernel have hundreds of vulnerabilities a year isn't helping. The baseline is way worse than any saboteur would be contributing. Such insecure-by-default projects make their job much easier. Hell, they can look pretty skilled only adding a few vulnerabilities to a project with that many.

jwfxpr 8y ago

Published 2013.

qalmakka 8y ago

While I love, loved, and will always love C, it has too many security dangers like these. I know it's not intrinsically its fault, and that you can mitigate lots of issues using better tooling, but many of the issues with C are due either to poor design choices (just look at the state of string.h) or things nobody could foresee decades ago. While being close to metal is of paramount importance for tasks such as writing kernels, we shouldn't be forced to pick between safety and simplicity; I think that C needs a treatment like C++11 has been to C++. Lots of people will stubbornly stick with C89, but a boy can hope, I guess.