6 ms·

Undisclosed hole in openssh on FreeBSD and Juniper?

48 points by Xylakant 13y ago

roeme 13y ago
Dupe. Previously: https://news.ycombinator.com/item?id=7568059 https://news.ycombinator.com/item?id=7568059
willvarfar 13y ago
If I parse Theo correctly, he clearly says that FreeBSD does have a hole. Its really really hard to imagine he is lying.
- fabulist 13y ago
  I'm guessing it is of modest severity, if they even feel they can _get away_ with keeping it to themselves. But its still deeply troubling.
davorb 13y ago
> Please ask Kirk McKusick, he knows the story about why this is not being disclosed to FreeBSD Could someone please explain this?
- Xylakant 13y ago
  I'd be curious as well.
fabulist 13y ago
What good reason could their possibly be for not disclosing a hole to FreeBSD? Especially if it effects networking infrastructure.... 1. Government gag order? I'd call this a "good reason", but it wouldn't clear my conscience. 2. Disclosure to or interception by malicious parties? I can't imagine that the best solution would be STO.
- Xylakant 13y ago
  > Government gag order I can't imagine a government gag order that allows you to publicly hint that there's a problem.
- xeroxmalf 13y ago
  It's not a good reason that they aren't disclosing, it's a personal reason.
- willvarfar 13y ago
  It could be that they plan to tell FreeBSD - and therefore expose what they've found, now they've suddenly started auditing OpenSSL consumers - only when they have a fix? It could be best fixed in OpenSSL itself, and only affecting those using the compiler options or SSH configuration that FreeBSD ships with.
  - lholden 13y ago
    OpenSSH is a SSH client and server provided by the Open BSD Foundation. OpenSSL is an encryption API maintained by an entirely different group of people. EDIT: Modified my reply. OpenSSH at some point moved it's "restrictively licenced software" (RSA, DES, etc) out of it's codebase and now depends on OpenSSL according to it's license. http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/LICENCE?rev=HEAD http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/LICENC...
    - willvarfar 13y ago
      Quite right, my typo, and if I could still 'edit' my post I'd correct it. I meant OpenSSH: It could be that they plan to tell FreeBSD - and therefore expose what they've found, now they've suddenly started auditing OpenSSH consumers - only when they have a fix? It could be best fixed in OpenSSH itself, and only affecting those using the compiler options or SSH configuration that FreeBSD ships with.
      - lholden 13y ago
icantthinkofone 13y ago
Theo is Sloppy Mo: https://www.youtube.com/watch?v=zKvhVssO348 https://www.youtube.com/watch?v=zKvhVssO348
awakened 13y ago
Many years ago, I submitted a bug report to OpenBSD about an issue I had discovered with threads. I received a one line response from Theo. I still have the mail. He wrote: "Threads are for idiots." At the time, I felt discounted and I was upset. I was younger then. Today, I realize what he meant and that he's right.
- markild 13y ago
  > I realize what he meant and that he's right. Could you please expand on this?
  - bananas 13y ago
    I think the rise of async/select based and privilege separated designs tend to suggest that threads don't work well for system programming.
    - tptacek 13y ago
      This is an incoherent response. Privilege separation is orthogonal to async designs. It's just as easy to privsep a synchronous program. Meanwhile, while I happen to appreciate async designs, it's far from settled as to whether they're long-term sounder than thread. What I know from experience is that it's easier to make async designs performant. Nothing I've seen suggests that they're that much safer.
      - bananas 13y ago
        Sorry I agree it was rather incoherent - I was distracted half way through posting. I'm not suggesting they are sounder but I'm suggesting that async designs are simpler and simplicity rules when it comes to safety. sync designs tend to evolve into complexity over time to maintain performance (IIS for example which is a behemoth of threaded privsep pain). And in my experience (so totally an anecdote and I accept that), it's not easier to privsep a synchronous program. On top of the IPC concerns of isolation, you still have all the problems associated with threading. It's just pain. (I've written a fair number of both types of systems - none open source unfortunately)
egwynn 13y ago
This is unsettling, to be sure. If there's anything to this, I'd really love to hear a response from the actual FreeBSD folks. But it should be noted that this guy has a relatively rocky history with *BSD, and his nearly context-free, ambiguous trash-talking of FreeBSD should be taken with a grain of salt.
jmnicolas 13y ago
Why would he say that and not reveal the vulnerability ?
pvg 13y ago
Dupe of https://news.ycombinator.com/item?id=7568059 https://news.ycombinator.com/item?id=7568059 and still flag button fodder.

48 points by Xylakant 13y ago

roeme 13y ago

Dupe. Previously: https://news.ycombinator.com/item?id=7568059 https://news.ycombinator.com/item?id=7568059

If I parse Theo correctly, he clearly says that FreeBSD does have a hole. Its really really hard to imagine he is lying.

fabulist 13y ago
I'm guessing it is of modest severity, if they even feel they can _get away_ with keeping it to themselves. But its still deeply troubling.

davorb 13y ago

> Please ask Kirk McKusick, he knows the story about why this is not being disclosed to FreeBSD Could someone please explain this?

Xylakant 13y ago
I'd be curious as well.

fabulist 13y ago

What good reason could their possibly be for not disclosing a hole to FreeBSD? Especially if it effects networking infrastructure.... 1. Government gag order? I'd call this a "good reason", but it wouldn't clear my conscience. 2. Disclosure to or interception by malicious parties? I can't imagine that the best solution would be STO.

Xylakant 13y ago
> Government gag order I can't imagine a government gag order that allows you to publicly hint that there's a problem.
xeroxmalf 13y ago
It's not a good reason that they aren't disclosing, it's a personal reason.
willvarfar 13y ago
It could be that they plan to tell FreeBSD - and therefore expose what they've found, now they've suddenly started auditing OpenSSL consumers - only when they have a fix? It could be best fixed in OpenSSL itself, and only affecting those using the compiler options or SSH configuration that FreeBSD ships with.
- lholden 13y ago
  OpenSSH is a SSH client and server provided by the Open BSD Foundation. OpenSSL is an encryption API maintained by an entirely different group of people. EDIT: Modified my reply. OpenSSH at some point moved it's "restrictively licenced software" (RSA, DES, etc) out of it's codebase and now depends on OpenSSL according to it's license. http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/LICENCE?rev=HEAD http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/LICENC...
  - willvarfar 13y ago
    Quite right, my typo, and if I could still 'edit' my post I'd correct it. I meant OpenSSH: It could be that they plan to tell FreeBSD - and therefore expose what they've found, now they've suddenly started auditing OpenSSH consumers - only when they have a fix? It could be best fixed in OpenSSH itself, and only affecting those using the compiler options or SSH configuration that FreeBSD ships with.
    - lholden 13y ago

icantthinkofone 13y ago

Theo is Sloppy Mo: https://www.youtube.com/watch?v=zKvhVssO348 https://www.youtube.com/watch?v=zKvhVssO348

awakened 13y ago

Many years ago, I submitted a bug report to OpenBSD about an issue I had discovered with threads. I received a one line response from Theo. I still have the mail. He wrote: "Threads are for idiots." At the time, I felt discounted and I was upset. I was younger then. Today, I realize what he meant and that he's right.

markild 13y ago
> I realize what he meant and that he's right. Could you please expand on this?
- bananas 13y ago
  I think the rise of async/select based and privilege separated designs tend to suggest that threads don't work well for system programming.
  - tptacek 13y ago
    This is an incoherent response. Privilege separation is orthogonal to async designs. It's just as easy to privsep a synchronous program. Meanwhile, while I happen to appreciate async designs, it's far from settled as to whether they're long-term sounder than thread. What I know from experience is that it's easier to make async designs performant. Nothing I've seen suggests that they're that much safer.
    - bananas 13y ago
      Sorry I agree it was rather incoherent - I was distracted half way through posting. I'm not suggesting they are sounder but I'm suggesting that async designs are simpler and simplicity rules when it comes to safety. sync designs tend to evolve into complexity over time to maintain performance (IIS for example which is a behemoth of threaded privsep pain). And in my experience (so totally an anecdote and I accept that), it's not easier to privsep a synchronous program. On top of the IPC concerns of isolation, you still have all the problems associated with threading. It's just pain. (I've written a fair number of both types of systems - none open source unfortunately)

egwynn 13y ago

This is unsettling, to be sure. If there's anything to this, I'd really love to hear a response from the actual FreeBSD folks. But it should be noted that this guy has a relatively rocky history with *BSD, and his nearly context-free, ambiguous trash-talking of FreeBSD should be taken with a grain of salt.

jmnicolas 13y ago

Why would he say that and not reveal the vulnerability ?

pvg 13y ago

Dupe of https://news.ycombinator.com/item?id=7568059 https://news.ycombinator.com/item?id=7568059 and still flag button fodder.