7 ms·

Is Apple wrong here? I mean, this is obviously a bad thing that should be fixed, but ultimately it amounts to a DoS against the machine and does not grant any p

Is Apple wrong here? I mean, this is obviously a bad thing that should be fixed, but ultimately it amounts to a DoS against the machine and does not grant any privileges or expose any data to the attacker. I can see why Apple might say it's not a "security" issue.

a012 9y ago
> " it amounts to a DoS against" but > "it's not a "security" issue" So contradict yourself. It's a feature, I guess.
clhodapp 9y ago
Not everyone agrees on this but an improper ability to cause a DOS is pretty widely considered to be a type of security issue.
- AstralStorm 9y ago
  This is not a simple DoS as in a service hangs. This is a reliable kill and potentially restart, making it possible to use fault injection attacks (not 100% reliable exploits) and exploit start-up race conditions.
  - viraptor 9y ago
    Or force-cleaning caches. Imagine you're trying to poison a DNS cache in some specific app. You can try+restart until you succeed.
jlgaddis 9y ago
A denial-of-service typically falls under the "availability" part of the "CIA triad" [0], although the seriousness can vary tremendously from one DoS to the next. [0]: https://en.wikipedia.org/wiki/Information_security#Key_concepts https://en.wikipedia.org/wiki/Information_security#Key_conce...
williamscales 9y ago
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.
KirinDave 9y ago
It is a security issue. The exposure is limited, but as folks point out; Apple forces people to build iOS binaries on machines running OSX. It'd be quite easy to DoS commercial build services with this technique and there seems to be no way to stop it and detecting it can be pretty difficult. Depending on how the logging for such a server is structured, it may even be hard to tell which customer did it. This is also on the heels of a bug that's been discovered where it's possible to hang many types of system monitoring by abusing a race condition in the UNIX<->mach layer to block all process inspection tools on the OS. Given that Apple forces us to run OSX build servers, they should take the integrity of basic syscall checking seriously. And that totally ignores the chaos one person with an agenda (or poor project security) can cause if they get code that does this into Homebrew.
- jakobegger 9y ago
  There are a lot of ways to DoS a commercial build service. If you let people execute arbitrary code on your machine, you better have logging in place to know who is responsible if your machine crashes. I'd assume that most build farms build on VMs to avoid exactly this kind of problem -- building on bare metal seems pretty risky.
  - oneweekwonder 9y ago
    > most build farms build on VMs Are one allowed to run macOS on a VM that is not apple hardware. Can you just buy macOS and run it on a vm, or is it a gray area?
    - ahakki 9y ago
      iirc macOS is only licensend to run on Apple hardware.
      - ctime 9y ago
        ..and only a single copy, it appears. These links are fun: https://github.com/kholia/OSX-KVM/blob/master/README.md https://github.com/kholia/OSX-KVM/blob/master/README.md http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/#sec_4 http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/#sec_4
dezgeg 9y ago
Besides a vulnerability, this bug is in fact a regression compared to previous macOS versions. In an API described by POSIX, no less.
- eridius 9y ago
  Yes, nobody's saying it's not a bug, and nobody's saying that it shouldn't be fixed. The only question is how to categorize it.

a012 9y ago

> " it amounts to a DoS against" but > "it's not a "security" issue" So contradict yourself. It's a feature, I guess.

clhodapp 9y ago

Not everyone agrees on this but an improper ability to cause a DOS is pretty widely considered to be a type of security issue.

AstralStorm 9y ago
This is not a simple DoS as in a service hangs. This is a reliable kill and potentially restart, making it possible to use fault injection attacks (not 100% reliable exploits) and exploit start-up race conditions.
- viraptor 9y ago
  Or force-cleaning caches. Imagine you're trying to poison a DNS cache in some specific app. You can try+restart until you succeed.

jlgaddis 9y ago

A denial-of-service typically falls under the "availability" part of the "CIA triad" [0], although the seriousness can vary tremendously from one DoS to the next. [0]: https://en.wikipedia.org/wiki/Information_security#Key_concepts https://en.wikipedia.org/wiki/Information_security#Key_conce...

williamscales 9y ago

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.

KirinDave 9y ago

It is a security issue. The exposure is limited, but as folks point out; Apple forces people to build iOS binaries on machines running OSX. It'd be quite easy to DoS commercial build services with this technique and there seems to be no way to stop it and detecting it can be pretty difficult. Depending on how the logging for such a server is structured, it may even be hard to tell which customer did it. This is also on the heels of a bug that's been discovered where it's possible to hang many types of system monitoring by abusing a race condition in the UNIX<->mach layer to block all process inspection tools on the OS. Given that Apple forces us to run OSX build servers, they should take the integrity of basic syscall checking seriously. And that totally ignores the chaos one person with an agenda (or poor project security) can cause if they get code that does this into Homebrew.

jakobegger 9y ago
There are a lot of ways to DoS a commercial build service. If you let people execute arbitrary code on your machine, you better have logging in place to know who is responsible if your machine crashes. I'd assume that most build farms build on VMs to avoid exactly this kind of problem -- building on bare metal seems pretty risky.
- oneweekwonder 9y ago
  > most build farms build on VMs Are one allowed to run macOS on a VM that is not apple hardware. Can you just buy macOS and run it on a vm, or is it a gray area?
  - ahakki 9y ago
    iirc macOS is only licensend to run on Apple hardware.
    - ctime 9y ago
      ..and only a single copy, it appears. These links are fun: https://github.com/kholia/OSX-KVM/blob/master/README.md https://github.com/kholia/OSX-KVM/blob/master/README.md http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/#sec_4 http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/#sec_4

dezgeg 9y ago

Besides a vulnerability, this bug is in fact a regression compared to previous macOS versions. In an API described by POSIX, no less.

eridius 9y ago
Yes, nobody's saying it's not a bug, and nobody's saying that it shouldn't be fixed. The only question is how to categorize it.