4 ms·

It seems to me that it's in the same category as a fork bomb - a neat trick requiring local access that will crash a machine. Deeming it a non-security bug seem

It seems to me that it's in the same category as a fork bomb - a neat trick requiring local access that will crash a machine. Deeming it a non-security bug seems entirely reasonable. As you say it does not grant any privileges or expose any data to the attacker. So the bug cannot really be exploited to compromise security except in a case where someone has gone to extraordinary lengths to keep even a local user from crashing the machine.

kbenson 9y ago
> So the bug cannot really be exploited to compromise security Do we really need to get into the discussion of how many times someone thought a bug wasn't a security problem or was unfeasible to use in an exploit in practice o ly to be proven wrong later as new techniques came about and were applied to the original problem? The unknown unknowns are the problem here, and they are as their name suggests, hard to nail down. Race conditions are a thing. My bet is a determined and smart hacker could find a way to weaponize this within a week at most.
- eridius 9y ago
  Just because a lot of bugs were thought hard/impossible to exploit and were later proven wrong does not mean every single bug is possible to exploit. Most software bugs are not exploitable. You just generally read about the ones that are.
  - AstralStorm 9y ago
    What this looks like is a useful step to exploit automatically restarting services.
  - akvadrako 9y ago
    > Most software bugs are not exploitable. I've never seen any evidence of that. Most bugs start you down rarely thought about paths and if you didn't map them out before hand all kinds of unexpected behavior could crop up.
    - crankylinuxuser 9y ago
      https://www.youtube.com/watch?v=OPcV9uIY5i4 https://www.youtube.com/watch?v=OPcV9uIY5i4 Video is about exploiting Super Mario world, on SNES. The result is that the exploiter then proceeds to make 2 new games inside SMW: Pong and Snake. Those games don't exist inside SMW. They were uploaded using controller inputs. All it takes is 1 hack.
      - eridius 9y ago
        Doesn't that hack allow you to write to arbitrary memory? Being able to write to attacker-controlled memory is a serious problem. That's not what the kill(-1) bug lets you do though.
        crankylinuxuser 9y ago
        The attack was a buffer overflow on handling objects in the "saved item" area at the top. By manipulating objects as done in the video, one can set RAM up as needed to construct the "program". Then when the overflow is executed, it jumps to the invalid place in memory, thus executing the code you seeded. This is also done in Pokemon Yellow with a link cable. The last time I saw this being done, a TAS hacker was able to inject a TCP stack over the link cable, and build an IRC client on top, and chat using the game boy. And I realize that's not the immediate action that bug has, regarding kill(-1). But I've seen what people thought were innocuous bugs that ended up being "gimmee root" kind of bugs.
  - kbenson 9y ago
    I'm not just making a general statement about all bugs, but also a specific statement about how I think this bug could play out. Not only does it kill all processes under the user, but it also crashes the entire system. Both of those are interesting bugs, and have possible implications if you can cause them in interesting situations. Can you cause some system process that happens to share the user with another, more interesting process to run a kill syscall? Can you cause the system to crash while some more trusted process is in the middle of updating a configuration, password, or other data structure that will cause interesting effects after the system is restarted? Both being able to cause other user processes to die, and to cause the system crash on demand as a user, are things I would consider individually as security problems just because they have a high probability of having unforeseen consequences. Having them together doubles the attack space (even if it does possibly create some problems with following through with a second action).
    - eridius 9y ago
      Killing all processes under the user is the expected behavior of kill(-1). That's perfectly fine. Crashing the system is the bug part. From the manpage: If pid is -1: If the user has super-user privileges, the signal is sent to all processes excluding system processes and the process sending the signal. If the user is not the super user, the signal is sent to all processes with the same uid as the user, excluding the process sending the signal. No error is returned if any process could be signaled.
      - kbenson 9y ago
        Fair enough, I really should have caught that. I guess it's been longer than I thought since I had to deal with that stuff. :/ It doesn't change the point I was trying to make much though.
- 13of40 9y ago
  I had to argue for the fix of more than one bug like this in another OS back in the day, and I take a more fundamental view of it: Does the OS have a security feature that's intended to prevent you from doing this? Does the exploit allow you to do it anyway? In this case the answer to both questions is "yes" which makes it a security bug.
  - Retric 9y ago
    Misspelling some random text in an application is generally not it a security issue. Website that don't render correctly when a screen resizes is again not a security issue. Sure, their are a lot of things that can become security issues, but a lot of code has little to do with how a program operates.
    - 13of40 9y ago
      Is there a security feature that's intended to prevent you from misspelling random text in an application?
      - Retric 9y ago
        I meant it like this: 'If the windows access control dialog box had "Cancell" instead of "Cancel" it's a bug in a security feature, but not an attack surface.' Now, you can make a semantic argument that it's a security issue based on what team needs to fix it, but IMO that's a meaningless distinction for users. What's distinct about a security bug is what it allows to happen.
        13of40 9y ago
        Sorry, I misunderstood you. In that case, the way I'd break it down is: Is that dialog a "security feature"? Sure. (Actually, that's a stretch, because it's just lipstick over the API, but...) Is it intended to block someone from being able to do something? No. I'm not saying these criteria are all inclusive - for example, if the buttons were mislabeled and "Cancel" actually applied ACL changes, I'd still call it a security bug. It seems like the bug this thread is talking about clearly does meet the criteria, though. If you look at the man page for kill[1] it says unless you're root, you're only allowed to kill processes running under your user, but the bug allows a low-privilege user to kill other users' processes. [1]https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man2/kill.2.html https://developer.apple.com/legacy/library/documentation/Dar...
- 013a 9y ago
  I'd say, at that point, it becomes a security issue. They'd probably agree. Just because it isn't categorized as a security issue doesn't mean their engineers aren't looking for solutions, even if they're publicly trying to downplay the issue. And just because its not a security issue today doesn't mean it can't be escalated into one when we know more about the exploit. They're not dumb. In fact, I'd say they're acting with more logic and measure than the alarmists in this thread.
  - kbenson 9y ago
    They may well be treating it intelligently inside the org (which is to say they may not be discounting and ignoring it entirely), which is a good thing. My response was more aimed towards the people here that took a less nuanced view, and assumed it wasn't exploitable or a security problem just because that's how an engineer initially categorized it. Every bug that causes the system to malfunction should be considered a possible security problem. The difference is how much severity you rate it and how quickly you decide to address it. It's the "So the bug cannot really be exploited to compromise security..." point of view I find dangerous. Historically it's led to quite a few problems.
pcnix 9y ago
Isn't a forkbomb the equivalent of a DoS attack though? So even if it doesn't grant any privileges or expose data, it is still part of the traditional security concerns.
caf 9y ago
It's possible to defend against fork bombs with appropriate user limits. This, not so much.
simias 9y ago
There are ways to protect against a fork bomb from an unprivileged user though, you can set per-user limits for number of process or memory use. If the OS didn't provide these mechanisms then yes I'd consider it a security issue.
- eridius 9y ago
  Technically you can protect against kill(-1) as well by ptracing the process and catching that call.

kbenson 9y ago

> So the bug cannot really be exploited to compromise security Do we really need to get into the discussion of how many times someone thought a bug wasn't a security problem or was unfeasible to use in an exploit in practice o ly to be proven wrong later as new techniques came about and were applied to the original problem? The unknown unknowns are the problem here, and they are as their name suggests, hard to nail down. Race conditions are a thing. My bet is a determined and smart hacker could find a way to weaponize this within a week at most.

eridius 9y ago
Just because a lot of bugs were thought hard/impossible to exploit and were later proven wrong does not mean every single bug is possible to exploit. Most software bugs are not exploitable. You just generally read about the ones that are.
- AstralStorm 9y ago
  What this looks like is a useful step to exploit automatically restarting services.
- akvadrako 9y ago
  > Most software bugs are not exploitable. I've never seen any evidence of that. Most bugs start you down rarely thought about paths and if you didn't map them out before hand all kinds of unexpected behavior could crop up.
  - crankylinuxuser 9y ago
    https://www.youtube.com/watch?v=OPcV9uIY5i4 https://www.youtube.com/watch?v=OPcV9uIY5i4 Video is about exploiting Super Mario world, on SNES. The result is that the exploiter then proceeds to make 2 new games inside SMW: Pong and Snake. Those games don't exist inside SMW. They were uploaded using controller inputs. All it takes is 1 hack.
    - eridius 9y ago
      Doesn't that hack allow you to write to arbitrary memory? Being able to write to attacker-controlled memory is a serious problem. That's not what the kill(-1) bug lets you do though.
      - crankylinuxuser 9y ago
        The attack was a buffer overflow on handling objects in the "saved item" area at the top. By manipulating objects as done in the video, one can set RAM up as needed to construct the "program". Then when the overflow is executed, it jumps to the invalid place in memory, thus executing the code you seeded. This is also done in Pokemon Yellow with a link cable. The last time I saw this being done, a TAS hacker was able to inject a TCP stack over the link cable, and build an IRC client on top, and chat using the game boy. And I realize that's not the immediate action that bug has, regarding kill(-1). But I've seen what people thought were innocuous bugs that ended up being "gimmee root" kind of bugs.
- kbenson 9y ago
  I'm not just making a general statement about all bugs, but also a specific statement about how I think this bug could play out. Not only does it kill all processes under the user, but it also crashes the entire system. Both of those are interesting bugs, and have possible implications if you can cause them in interesting situations. Can you cause some system process that happens to share the user with another, more interesting process to run a kill syscall? Can you cause the system to crash while some more trusted process is in the middle of updating a configuration, password, or other data structure that will cause interesting effects after the system is restarted? Both being able to cause other user processes to die, and to cause the system crash on demand as a user, are things I would consider individually as security problems just because they have a high probability of having unforeseen consequences. Having them together doubles the attack space (even if it does possibly create some problems with following through with a second action).
  - eridius 9y ago
    Killing all processes under the user is the expected behavior of kill(-1). That's perfectly fine. Crashing the system is the bug part. From the manpage: If pid is -1: If the user has super-user privileges, the signal is sent to all processes excluding system processes and the process sending the signal. If the user is not the super user, the signal is sent to all processes with the same uid as the user, excluding the process sending the signal. No error is returned if any process could be signaled.
    - kbenson 9y ago
      Fair enough, I really should have caught that. I guess it's been longer than I thought since I had to deal with that stuff. :/ It doesn't change the point I was trying to make much though.
13of40 9y ago
I had to argue for the fix of more than one bug like this in another OS back in the day, and I take a more fundamental view of it: Does the OS have a security feature that's intended to prevent you from doing this? Does the exploit allow you to do it anyway? In this case the answer to both questions is "yes" which makes it a security bug.
- Retric 9y ago
  Misspelling some random text in an application is generally not it a security issue. Website that don't render correctly when a screen resizes is again not a security issue. Sure, their are a lot of things that can become security issues, but a lot of code has little to do with how a program operates.
  - 13of40 9y ago
    Is there a security feature that's intended to prevent you from misspelling random text in an application?
    - Retric 9y ago
      I meant it like this: 'If the windows access control dialog box had "Cancell" instead of "Cancel" it's a bug in a security feature, but not an attack surface.' Now, you can make a semantic argument that it's a security issue based on what team needs to fix it, but IMO that's a meaningless distinction for users. What's distinct about a security bug is what it allows to happen.
      - 13of40 9y ago
        Sorry, I misunderstood you. In that case, the way I'd break it down is: Is that dialog a "security feature"? Sure. (Actually, that's a stretch, because it's just lipstick over the API, but...) Is it intended to block someone from being able to do something? No. I'm not saying these criteria are all inclusive - for example, if the buttons were mislabeled and "Cancel" actually applied ACL changes, I'd still call it a security bug. It seems like the bug this thread is talking about clearly does meet the criteria, though. If you look at the man page for kill[1] it says unless you're root, you're only allowed to kill processes running under your user, but the bug allows a low-privilege user to kill other users' processes. [1]https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man2/kill.2.html https://developer.apple.com/legacy/library/documentation/Dar...
013a 9y ago
I'd say, at that point, it becomes a security issue. They'd probably agree. Just because it isn't categorized as a security issue doesn't mean their engineers aren't looking for solutions, even if they're publicly trying to downplay the issue. And just because its not a security issue today doesn't mean it can't be escalated into one when we know more about the exploit. They're not dumb. In fact, I'd say they're acting with more logic and measure than the alarmists in this thread.
- kbenson 9y ago
  They may well be treating it intelligently inside the org (which is to say they may not be discounting and ignoring it entirely), which is a good thing. My response was more aimed towards the people here that took a less nuanced view, and assumed it wasn't exploitable or a security problem just because that's how an engineer initially categorized it. Every bug that causes the system to malfunction should be considered a possible security problem. The difference is how much severity you rate it and how quickly you decide to address it. It's the "So the bug cannot really be exploited to compromise security..." point of view I find dangerous. Historically it's led to quite a few problems.

pcnix 9y ago

Isn't a forkbomb the equivalent of a DoS attack though? So even if it doesn't grant any privileges or expose data, it is still part of the traditional security concerns.

caf 9y ago

It's possible to defend against fork bombs with appropriate user limits. This, not so much.

simias 9y ago

There are ways to protect against a fork bomb from an unprivileged user though, you can set per-user limits for number of process or memory use. If the OS didn't provide these mechanisms then yes I'd consider it a security issue.

eridius 9y ago
Technically you can protect against kill(-1) as well by ptracing the process and catching that call.