6 ms·

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 softw

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.

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.