7 ms·

Multiple Bugs in OpenBSD Kernel

199 points by hassel 10y ago

jwilk 10y ago
More readable archived copy: http://permalink.gmane.org/gmane.comp.security.oss.general/19946 http://permalink.gmane.org/gmane.comp.security.oss.general/1... (I'm not a fan of gmane, but it did a better job with this particular mail than the alternatives.)
- jfb 10y ago
  The gmane interface is so bad it beggars belief.
  - lomnakkus 10y ago
    Heh -- it kind of makes sense since it's really meant to be used via NNTP. (That's the whole raison d'être for GMANE.)
    - jfb 10y ago
      Yeah, I get that, but the HTML interface is so awful I think we'd all be better off if we just used Gnus to read it.
  - puetzk 10y ago
    Classic view is better for nested threads: http://thread.gmane.org/gmane.comp.security.oss.general/19946 http://thread.gmane.org/gmane.comp.security.oss.general/1994...
  - deathanatos 10y ago
    Yes, but at least it bothered to parse the email and display it? The original URL seems to have very nearly just echoed the raw MIME message into an HTML page.
  - cm3 10y ago
    FWIW, I find Gmane much easier to use than Google Groups. It doesn't take ages to asynchronously load via JS and then hijack common browser behavior or make it harder to use the browsers history mechanism to return to where the tab was closed. Gmane's servers are slow, but the interface is much easier to use because it's a simple design.
lifeisstillgood 10y ago
Fuzzing is not something I have looked at seriously (to be honest it seems like asking clients to take up running before walking) but the outcomes are ... Impressive.
- Matt3o12_ 10y ago
  How come? What better way to test your function then giving them random/unexpected input and see how that works out. Would you not want to try out what happens if I pulled a door you built that is only meant for pushing? There will always be that one person who ignores the sign and tries pulling just like there is always that person who uses your function in an unexpected way.
  - kbenson 10y ago
    I took it more as there are fundamentals that could be focused on first. If you know your door is a piece of plywood leaning against the opening, yout time may be better spent getting a real door before you start testing all the ways plywood can fail. If you aren't in the habit of using debris for structural items, sure, spend some time testing failure modes. :)
    - lifeisstillgood 10y ago
      Exactly - these days table stakes is having a CI test suite with unit tests with good coverage, good integration tests (with the attendant "so I need four servers plus a couple to fire the tests ... Oh") and wait what you want UI testing ? Oh.
  - runeks 10y ago
    The issue I have with tests, is that I feel like I'm just implementing my algorithm a second time, in a different wording (language/domain), hoping that this will catch some unknown bug(s). If a test suite covers all aspects of an implementation, it's basically a second implementation, and then the question becomes whether the time spent writing this test code would actually have been better spent looking over the actual code that defines your algorithm. If we can't detect errors in code by reading it, I don't think tests will help us much. Furthermore: if our algorithms require a second "test implementation", shouldn't we also write a test for the test, to confirm that the written test actually tests correctly? What good is a broken test? If you've built a plywood door, and a machine for testing that door, wouldn't it be useful to have a machine that tests that your testing machine actually tests the door properly? All jokes aside, I really enjoy automated, high-level tests, which mimic actual user behaviour. I think this is different because we're no longer implementing an algorithm a second time around (as a test), but rather encoding user behaviour (of the algorithm) into an algorithm (new code).
smhenderson 10y ago
While a bit surprising to see so many at once in OBSD kudos to the team for the rapid response and to those who found the bugs for their responsible disclosure.
rhabarba 10y ago
Multiple (!) security issues in OpenBSD (!). OK. We're doomed.
- PeCaN 10y ago
  At least these (seem to) result in a kernel panic instead of privileged escalation or reading unauthorized memory. But in a world where even djbdns had a (minor) security issue, I don't think it's reasonable to expect any non-trivial software—particularly software written in C—to be fully secure.
  - caf 10y ago
    The mmap_panic one does seem to have the possibility of privilege escalation.
  - ams6110 10y ago
    I found it interesting that most of the patches are one or two line changes. Shows how one tiny oversight can open up a DoS or security vulnerablity.
SEJeff 10y ago
And for those not aware, Project Triforce, is NCC's effort to run the wonderful fuzzer American Fuzzy Lop, on everything: https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2016/june/project-triforce-run-afl-on-everything/ https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...
- yeukhon 10y ago
  Being nitpick because I dislike clickbait. With the use of comma, ", on everything" is an emphasis. Emphasizing "everything" sounds to me they want to run AFL on everything, including Hacker News I guess? Because if everything doesn't include EVERYTHING, then everything isn't really everything.
  - pg_is_a_butt 10y ago
    everything they have access to is relatively "everything". you are an idiot, on everything.
  - madgar 10y ago
    It isn't "clickbait" just because natural language contains semantic ambiguity. Contextual clues - both textual and cultural - indicate that "everything" here is limited to software and not all things in existence, and to go further, open-source software. Natural language would cease to function were it not for audience's ability to disambiguate based on context.
    - yeukhon 10y ago
      It is a clickbait if a technical person and a technical company are speaking ambiguously. HN itself is a property made up of layers of software and hardware which partially fall into the the "everything [software]" list. If you think I am taking way out of context, that's right, because technologists should not talk like a futurist. That's my point. If this were an article titled "Google AI can understand everything!" but the "everything" is limited to just figuring out a cat video, that would be considered a marketing clickbait. So why are we giving a pass on this article?
djcapelis 10y ago
It sounds like one local privilege escalation (possibly?) and a series of crashers? Honestly walking away with those being the highest severity bugs is a credit to the OpenBSD team and their focus on security. They're totally bugs and it sounds like they're getting fixed immediately, but... many kernels fix these types of things all the time and don't even consider them security bugs.
- cbreeden 10y ago
  Ya I was quite impressed.
- deleted 10y ago
  [deleted]
- viraptor 10y ago
  Those bugs come from syscall fuzzing. Local privilege escalation is the worst thing you can get from it, so the results are as bad as they can be (apart from finding multiple privilege escalations that is).
  - djcapelis 10y ago
    I see your point, but it doesn't happen to be true, a bug in recv, send or other networking syscalls certainly could be much worse than a local priv escalation. And seriously, only one local priv escalation and some crashers is still a pretty light haul for a good fuzzing session from a competent team. The sky is not falling for OpenBSD today.
    - viraptor 10y ago
      > a bug in recv, send or other networking syscalls certainly could be much worse than a local priv escalation I think that's very unlikely. Since most of the socket API ignores the payload (it's just opaque data), I don't see how recv/send issue could be triggered from outside. Syscall vulnerabilities are usually based on bad flags, bad addresses, or type confusions. Normally you have to have local access to control those.
gbrown_ 10y ago
Firstly glad to see these reported and fixed. Secondly how many of these were remotely exploitable? Yes OpenBSD is limited in it's exposure with the "base system", but it seems like few of these pose as "holes" for the system? Arguably pledge(2) could factor into this, maybe? I'll let someone better qualified comment. Again glad to see these fixed. But is the baseline free user access to the whole system for NetSec/ OpSec these days? I don't know maybe it is. I'm just reluctant to have to read through the HN, "OMG OpenBSD had CVEs" and "C is insecure". Arguably the later has some merit but C isn't going away anytime soon, for better or for worse.
- caf 10y ago
  Direct remote privilege escalation exploits in kernels are relatively rare. The usual attack path is exploiting an application bug for local user access, followed by a local privilege escalation.
- viraptor 10y ago
  > Secondly how many of these were remotely exploitable? I don't think this is a valid question. The vulnerabilities are in syscalls. Unless some application exposes them in a very unexpected way, they're local-only by design.
epmatsw 10y ago
I wish someone would release something like Fuzzing At Home. I've got computer power to throw at it, but I don't really have the expertise to do the setup work...
- runeks 10y ago
  The last time I tried to compile an executable using all the afl fuzzer magic-compile-time stuff, I gave up, so I have the impression that CPU time isn't the bottleneck here.
  - quentusrex 10y ago
    It took me a day to understand the tooling required to get AFL working. Now I can spin up a new test case for a library within a couple hours. Once you have the test case, then it is CPU bound. I had on one series of tests, of the baresip sip library libre, running across 4 machines(24 cores each) for a day before it was 100% sure it had tested every code path looking for a SIP protocol decoding error through fuzzing.
    - voltagex_ 10y ago
      How did you split up the work across the machines?
      - justinclift 10y ago
        AFL has documentation on how to setup that up. eg: https://github.com/mcarpenter/afl/blob/master/docs/parallel_fuzzing.txt
  - epmatsw 10y ago
    This is part of my problem. The other part is that I just don't know where to look. I'd much rather have some board choose submitted areas of open source projects, have the submitter/community create a harness, and then run something like Folding@home in a Docker container.
- 10y ago
lbradstreet 10y ago
It's striking how many of these issues cause panics because of assertions that were already in the code. Without good assertion use, I would assume that many of these would have been much worse.
djgs 10y ago
Ted U. announced that usermount will be removed in OpenBSD 6.0 https://marc.info/?l=openbsd-announce&m=146854517406640&w=2 https://marc.info/?l=openbsd-announce&m=146854517406640&w=2
- ams6110 10y ago
  So I wonder what the approach will be to allow users to mount USB flash drives?
  - ben_bai 10y ago
    doas(1), sudo(8), hotplugd(8), ...
hiphopyo 10y ago
Compared to other OSes and distros this is one in a million.

199 points by hassel 10y ago

jwilk 10y ago

More readable archived copy: http://permalink.gmane.org/gmane.comp.security.oss.general/19946 http://permalink.gmane.org/gmane.comp.security.oss.general/1... (I'm not a fan of gmane, but it did a better job with this particular mail than the alternatives.)

jfb 10y ago
The gmane interface is so bad it beggars belief.
- lomnakkus 10y ago
  Heh -- it kind of makes sense since it's really meant to be used via NNTP. (That's the whole raison d'être for GMANE.)
  - jfb 10y ago
    Yeah, I get that, but the HTML interface is so awful I think we'd all be better off if we just used Gnus to read it.
- puetzk 10y ago
  Classic view is better for nested threads: http://thread.gmane.org/gmane.comp.security.oss.general/19946 http://thread.gmane.org/gmane.comp.security.oss.general/1994...
- deathanatos 10y ago
  Yes, but at least it bothered to parse the email and display it? The original URL seems to have very nearly just echoed the raw MIME message into an HTML page.
- cm3 10y ago
  FWIW, I find Gmane much easier to use than Google Groups. It doesn't take ages to asynchronously load via JS and then hijack common browser behavior or make it harder to use the browsers history mechanism to return to where the tab was closed. Gmane's servers are slow, but the interface is much easier to use because it's a simple design.

lifeisstillgood 10y ago

Fuzzing is not something I have looked at seriously (to be honest it seems like asking clients to take up running before walking) but the outcomes are ... Impressive.

Matt3o12_ 10y ago
How come? What better way to test your function then giving them random/unexpected input and see how that works out. Would you not want to try out what happens if I pulled a door you built that is only meant for pushing? There will always be that one person who ignores the sign and tries pulling just like there is always that person who uses your function in an unexpected way.
- kbenson 10y ago
  I took it more as there are fundamentals that could be focused on first. If you know your door is a piece of plywood leaning against the opening, yout time may be better spent getting a real door before you start testing all the ways plywood can fail. If you aren't in the habit of using debris for structural items, sure, spend some time testing failure modes. :)
  - lifeisstillgood 10y ago
    Exactly - these days table stakes is having a CI test suite with unit tests with good coverage, good integration tests (with the attendant "so I need four servers plus a couple to fire the tests ... Oh") and wait what you want UI testing ? Oh.
- runeks 10y ago
  The issue I have with tests, is that I feel like I'm just implementing my algorithm a second time, in a different wording (language/domain), hoping that this will catch some unknown bug(s). If a test suite covers all aspects of an implementation, it's basically a second implementation, and then the question becomes whether the time spent writing this test code would actually have been better spent looking over the actual code that defines your algorithm. If we can't detect errors in code by reading it, I don't think tests will help us much. Furthermore: if our algorithms require a second "test implementation", shouldn't we also write a test for the test, to confirm that the written test actually tests correctly? What good is a broken test? If you've built a plywood door, and a machine for testing that door, wouldn't it be useful to have a machine that tests that your testing machine actually tests the door properly? All jokes aside, I really enjoy automated, high-level tests, which mimic actual user behaviour. I think this is different because we're no longer implementing an algorithm a second time around (as a test), but rather encoding user behaviour (of the algorithm) into an algorithm (new code).

smhenderson 10y ago

While a bit surprising to see so many at once in OBSD kudos to the team for the rapid response and to those who found the bugs for their responsible disclosure.

rhabarba 10y ago

Multiple (!) security issues in OpenBSD (!). OK. We're doomed.

PeCaN 10y ago
At least these (seem to) result in a kernel panic instead of privileged escalation or reading unauthorized memory. But in a world where even djbdns had a (minor) security issue, I don't think it's reasonable to expect any non-trivial software—particularly software written in C—to be fully secure.
- caf 10y ago
  The mmap_panic one does seem to have the possibility of privilege escalation.
- ams6110 10y ago
  I found it interesting that most of the patches are one or two line changes. Shows how one tiny oversight can open up a DoS or security vulnerablity.

SEJeff 10y ago

And for those not aware, Project Triforce, is NCC's effort to run the wonderful fuzzer American Fuzzy Lop, on everything: https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2016/june/project-triforce-run-afl-on-everything/ https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...

yeukhon 10y ago
Being nitpick because I dislike clickbait. With the use of comma, ", on everything" is an emphasis. Emphasizing "everything" sounds to me they want to run AFL on everything, including Hacker News I guess? Because if everything doesn't include EVERYTHING, then everything isn't really everything.
- pg_is_a_butt 10y ago
  everything they have access to is relatively "everything". you are an idiot, on everything.
- madgar 10y ago
  It isn't "clickbait" just because natural language contains semantic ambiguity. Contextual clues - both textual and cultural - indicate that "everything" here is limited to software and not all things in existence, and to go further, open-source software. Natural language would cease to function were it not for audience's ability to disambiguate based on context.
  - yeukhon 10y ago
    It is a clickbait if a technical person and a technical company are speaking ambiguously. HN itself is a property made up of layers of software and hardware which partially fall into the the "everything [software]" list. If you think I am taking way out of context, that's right, because technologists should not talk like a futurist. That's my point. If this were an article titled "Google AI can understand everything!" but the "everything" is limited to just figuring out a cat video, that would be considered a marketing clickbait. So why are we giving a pass on this article?

djcapelis 10y ago

It sounds like one local privilege escalation (possibly?) and a series of crashers? Honestly walking away with those being the highest severity bugs is a credit to the OpenBSD team and their focus on security. They're totally bugs and it sounds like they're getting fixed immediately, but... many kernels fix these types of things all the time and don't even consider them security bugs.

cbreeden 10y ago
Ya I was quite impressed.
deleted 10y ago
[deleted]
viraptor 10y ago
Those bugs come from syscall fuzzing. Local privilege escalation is the worst thing you can get from it, so the results are as bad as they can be (apart from finding multiple privilege escalations that is).
- djcapelis 10y ago
  I see your point, but it doesn't happen to be true, a bug in recv, send or other networking syscalls certainly could be much worse than a local priv escalation. And seriously, only one local priv escalation and some crashers is still a pretty light haul for a good fuzzing session from a competent team. The sky is not falling for OpenBSD today.
  - viraptor 10y ago
    > a bug in recv, send or other networking syscalls certainly could be much worse than a local priv escalation I think that's very unlikely. Since most of the socket API ignores the payload (it's just opaque data), I don't see how recv/send issue could be triggered from outside. Syscall vulnerabilities are usually based on bad flags, bad addresses, or type confusions. Normally you have to have local access to control those.

gbrown_ 10y ago

Firstly glad to see these reported and fixed. Secondly how many of these were remotely exploitable? Yes OpenBSD is limited in it's exposure with the "base system", but it seems like few of these pose as "holes" for the system? Arguably pledge(2) could factor into this, maybe? I'll let someone better qualified comment. Again glad to see these fixed. But is the baseline free user access to the whole system for NetSec/ OpSec these days? I don't know maybe it is. I'm just reluctant to have to read through the HN, "OMG OpenBSD had CVEs" and "C is insecure". Arguably the later has some merit but C isn't going away anytime soon, for better or for worse.

caf 10y ago
Direct remote privilege escalation exploits in kernels are relatively rare. The usual attack path is exploiting an application bug for local user access, followed by a local privilege escalation.
viraptor 10y ago
> Secondly how many of these were remotely exploitable? I don't think this is a valid question. The vulnerabilities are in syscalls. Unless some application exposes them in a very unexpected way, they're local-only by design.

epmatsw 10y ago

I wish someone would release something like Fuzzing At Home. I've got computer power to throw at it, but I don't really have the expertise to do the setup work...

runeks 10y ago
The last time I tried to compile an executable using all the afl fuzzer magic-compile-time stuff, I gave up, so I have the impression that CPU time isn't the bottleneck here.
- quentusrex 10y ago
  It took me a day to understand the tooling required to get AFL working. Now I can spin up a new test case for a library within a couple hours. Once you have the test case, then it is CPU bound. I had on one series of tests, of the baresip sip library libre, running across 4 machines(24 cores each) for a day before it was 100% sure it had tested every code path looking for a SIP protocol decoding error through fuzzing.
  - voltagex_ 10y ago
    How did you split up the work across the machines?
    - justinclift 10y ago
      AFL has documentation on how to setup that up. eg: https://github.com/mcarpenter/afl/blob/master/docs/parallel_fuzzing.txt
- epmatsw 10y ago
  This is part of my problem. The other part is that I just don't know where to look. I'd much rather have some board choose submitted areas of open source projects, have the submitter/community create a harness, and then run something like Folding@home in a Docker container.
10y ago

lbradstreet 10y ago

It's striking how many of these issues cause panics because of assertions that were already in the code. Without good assertion use, I would assume that many of these would have been much worse.

djgs 10y ago

Ted U. announced that usermount will be removed in OpenBSD 6.0 https://marc.info/?l=openbsd-announce&m=146854517406640&w=2 https://marc.info/?l=openbsd-announce&m=146854517406640&w=2

ams6110 10y ago
So I wonder what the approach will be to allow users to mount USB flash drives?
- ben_bai 10y ago
  doas(1), sudo(8), hotplugd(8), ...

hiphopyo 10y ago

Compared to other OSes and distros this is one in a million.