Undisclosed hole in openssh on FreeBSD and Juniper?(thread.gmane.org)
thread.gmane.org
Undisclosed hole in openssh on FreeBSD and Juniper?
http://thread.gmane.org/gmane.os.openbsd.tech/35722/focus=35731
46 comments
This is vintage Theo. It has the virtue of sounding correct, but, because OpenBSD ships threaded libraries, it probably lacks the virtue of being correct.
I had a similar experience (note, though: I have a history with Theo, who I know/knew personally).
When I was at Arbor Networks, we shipped appliances that monitored ISP backbones that were based on OpenBSD. An analysis process that happened to allocate a lot of memory would occasionally lose a giant chunk of memory. I was able to produce a reduction of the bug and narrow down where in the VM subsystem the bug was happening, but I wasn't able to recommend a fix. Theo's response, to what was clearly a serious bug in OpenBSD, was "I'm not going to look at UVM; it's just Chuck Cranor's thesis project".
I lobbied for a switch to FreeBSD, but the monkey.org people that ran the place were dyed-in-the-wool for OpenBSD. :)
I had a similar experience (note, though: I have a history with Theo, who I know/knew personally).
When I was at Arbor Networks, we shipped appliances that monitored ISP backbones that were based on OpenBSD. An analysis process that happened to allocate a lot of memory would occasionally lose a giant chunk of memory. I was able to produce a reduction of the bug and narrow down where in the VM subsystem the bug was happening, but I wasn't able to recommend a fix. Theo's response, to what was clearly a serious bug in OpenBSD, was "I'm not going to look at UVM; it's just Chuck Cranor's thesis project".
I lobbied for a switch to FreeBSD, but the monkey.org people that ran the place were dyed-in-the-wool for OpenBSD. :)
What happened next? Did the bug get fixed? Did you do a work-around somehow? Don't leave stories unfinished like this :)
I actually don't know. Arbor could have had its dev team hunt for a fix for the bug, but that would have been silly; no way did it make sense for them to take ownership of a custom fork of the most complicated kernel subsystem. So we worked around the problem instead.
In the beginning, when Theo was cast out of NetBSD, someone rewrote this thing
http://www.skrause.org/humor/poohgoesapeshit.shtml
with Theo and other BSD-ish personalities as the characters. There are many stories of prickly people mellowing with age. It's unlikely there'll be such a story about him.
http://www.skrause.org/humor/poohgoesapeshit.shtml
with Theo and other BSD-ish personalities as the characters. There are many stories of prickly people mellowing with age. It's unlikely there'll be such a story about him.
I don't see how his response was unreasonable.
It helps to understand the role a virtual memory system has in an operating system kernel.
Its also important to choose your security battles. I imagine there was another severe bug or two in a project as large as OpenBSD.
That being said, thats a petty and ridiculous reason not to deal with someone's code. This gentleman strikes be as a builder, not a maintainer; someone who wants to breeze through town like a cowboy, bring cool ideas to fruition, and move on to the next conquest while someone else keeps the system from falling apart. Thats not a judgment, we need people like that, but they probably shouldn't be the ones fielding emails.
That being said, thats a petty and ridiculous reason not to deal with someone's code. This gentleman strikes be as a builder, not a maintainer; someone who wants to breeze through town like a cowboy, bring cool ideas to fruition, and move on to the next conquest while someone else keeps the system from falling apart. Thats not a judgment, we need people like that, but they probably shouldn't be the ones fielding emails.
> I realize what he meant and that he's right.
Could you please expand on this?
Could you please expand on this?
I think the rise of async/select based and privilege separated designs tend to suggest that threads don't work well for system programming.
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.
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)
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)
Great story. It is good to know that some programmers do learn over time.
For every 1 story like yours there are probably 10 where someone is still traying to get "revenge" by saying nasty things about you know who.
Those more common stories get replicated through the wires and the end result is that no one cares about programming anymore; they are simply interested in discussing interpersonal relations.
Would you rather have your software written by a foolish programmer who is pleasantly tactful or a competent and conservative one who is tactless?
The answer of course varies depending on what you are really after.
For every 1 story like yours there are probably 10 where someone is still traying to get "revenge" by saying nasty things about you know who.
Those more common stories get replicated through the wires and the end result is that no one cares about programming anymore; they are simply interested in discussing interpersonal relations.
Would you rather have your software written by a foolish programmer who is pleasantly tactful or a competent and conservative one who is tactless?
The answer of course varies depending on what you are really after.
> Would you rather have your software written by a foolish programmer who is pleasantly tactful or a competent and conservative one who is tactless?
This is a false dichotomy. Interpersonal skills are among the skills necessary to work on a project that involves more than one person. That covers most of the interesting ones. If there's a successful project with someone who lacks those skills, it's because other people are covering for them -- just like a successful project with a foolish programmer. Sometimes that person makes up for it with other things they bring to the table, and that's fine, but don't pretend a weakness is a virtue.
This is a false dichotomy. Interpersonal skills are among the skills necessary to work on a project that involves more than one person. That covers most of the interesting ones. If there's a successful project with someone who lacks those skills, it's because other people are covering for them -- just like a successful project with a foolish programmer. Sometimes that person makes up for it with other things they bring to the table, and that's fine, but don't pretend a weakness is a virtue.
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.
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.
Short Answer: Bitterness.
Long Answer: It's complicated and I do not understand the whole picture myself.
I can however outline two things that likely exasperate the situation.
a) OpenSSH is used by nearly everyone. Nearly every unix-like installation includes a copy of OpenSSH. Most companies which do business on the internet use a unix-like operating system in some way.
The OpenBSD Foundation has had trouble obtaining funding to cover operating costs in the past. Included in these operating costs is support and auditing of OpenSSH.
b) There has been a long and colored history between FreeBSD and OpenBSD. A lot of code and features developed under OpenBSD has been ported over to FreeBSD such as the OpenBSD Packet Filter (PF).
Juniper uses FreeBSD and PF in their routers and have donated in various ways to FreeBSD. For example, Juniper donated three EX3200s with full contracts to FreeBSD for use in their datacenter.
The OpenBSD Foundation on the other hand has not really seen the same support.
Long Answer: It's complicated and I do not understand the whole picture myself.
I can however outline two things that likely exasperate the situation.
a) OpenSSH is used by nearly everyone. Nearly every unix-like installation includes a copy of OpenSSH. Most companies which do business on the internet use a unix-like operating system in some way.
The OpenBSD Foundation has had trouble obtaining funding to cover operating costs in the past. Included in these operating costs is support and auditing of OpenSSH.
b) There has been a long and colored history between FreeBSD and OpenBSD. A lot of code and features developed under OpenBSD has been ported over to FreeBSD such as the OpenBSD Packet Filter (PF).
Juniper uses FreeBSD and PF in their routers and have donated in various ways to FreeBSD. For example, Juniper donated three EX3200s with full contracts to FreeBSD for use in their datacenter.
The OpenBSD Foundation on the other hand has not really seen the same support.
Sure, De Raadt/OpenBSD are bitter about the lack of funding but that does not explain anything about this mysterious hole.
This email can mean anything. Does Kirk McKusick know about this hole and has he pressured De Raadt not to disclose it (for what reason could that even be?), or is it a vague reference to a fallout he had with him earlier(making this an absurdly petty reason not to disclose it)?
Just dropping that hint is ambiguous drama baiting.
Just dropping that hint is ambiguous drama baiting.
Drama baiting is something Theo de Raadt is good at. :)
I have a feeling it has less to do with something sinister, and more to do with Theo's very vocal stance on the security situation in FreeBSD.
http://www.itwire.com/business-it-news/open-source/62641-cry...
Most likely the FreeBSD kernel or libraries are doing something in a certain way that Theo finds insecure/insufficient. (Justified or not)
I have a feeling it has less to do with something sinister, and more to do with Theo's very vocal stance on the security situation in FreeBSD.
http://www.itwire.com/business-it-news/open-source/62641-cry...
Most likely the FreeBSD kernel or libraries are doing something in a certain way that Theo finds insecure/insufficient. (Justified or not)
FreeBSD dev response to De Raadt's very vocal stance: http://tech.slashdot.org/comments.pl?sid=4559455&cid=4570198...
It really does seem like De Raadt's just being really petty to me. But if this is an actual hole and he doesn't want to say what it is, that is worrisome. Doesn't he insinuate the rest of FreeBSD does not know about the hole?
It really does seem like De Raadt's just being really petty to me. But if this is an actual hole and he doesn't want to say what it is, that is worrisome. Doesn't he insinuate the rest of FreeBSD does not know about the hole?
It's Theo de Raadt...
It's possible that he knows of a real exploitable problem.
It's possible that he is trying to boast about his prowess with things "security".
It's possible the "hole" is a design feature in FreeBSD that he just doesn't like. (And hence, considers to be a security problem.)
It's possible that he is bitter that FreeBSD has gotten more attention than OpenBSD.
It's possible that he said it to spur FreeBSD take more interest in security. (Justifiably or not...)
It's possible that he wanted to cause a commotion.
It's possible that more than one of the above is true. :) He is under no obligation to make a disclosure of an exploit that he finds. Does it make him a bad net-denizen? Perhaps. But it's his prerogative.
It's possible that he knows of a real exploitable problem.
It's possible that he is trying to boast about his prowess with things "security".
It's possible the "hole" is a design feature in FreeBSD that he just doesn't like. (And hence, considers to be a security problem.)
It's possible that he is bitter that FreeBSD has gotten more attention than OpenBSD.
It's possible that he said it to spur FreeBSD take more interest in security. (Justifiably or not...)
It's possible that he wanted to cause a commotion.
It's possible that more than one of the above is true. :) He is under no obligation to make a disclosure of an exploit that he finds. Does it make him a bad net-denizen? Perhaps. But it's his prerogative.
Thank you for sharing your insight.
It's not a good reason that they aren't disclosing, it's a personal reason.
> Government gag order
I can't imagine a government gag order that allows you to publicly hint that there's a problem.
I can't imagine a government gag order that allows you to publicly hint that there's a problem.
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.
It could be best fixed in OpenSSL itself, and only affecting those using the compiler options or SSH configuration that FreeBSD ships with.
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/LICENC...
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/LICENC...
Actually somebody posted the contrary yesterday and I thought the same as you. We're both wrong - I went off and checked the openssl license and it lists a couple of things that are included from OpenSSL and a short grep in the code turns up a lot of references to OpenSSL.
Crazy... Modified my post. Thanks :)
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.
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.
No worries. My reply turned out ot be not entirely correct either so :D
RSA, DES, etc are not "restrictively licensed software", they are algorithms in the public domain. Anybody can write their own implementation of it and license that work how they see fit - including OpenSSH. I'm pretty sure they're just lazy and would rather use someone else's code.
RSA was patent encumbered at the time the clause was made to the OpenSSH license. This very likely qualified RSA as "restrictively licensed". RSA was released from its patent in 2000 (just weeks before it expired).
DSA I believe is still patent encumbered.
DSA I believe is still patent encumbered.
Right. They've had 14 years to re-add code like RSA and Diffie-Hellman to their project if they wanted to. Lazy programmers.
NIST made the DSA patent available worldwide royalty-free. In fact, DSA was unencumbered by patents before RSA, which is why SSH version 2 incorporated it.
NIST made the DSA patent available worldwide royalty-free. In fact, DSA was unencumbered by patents before RSA, which is why SSH version 2 incorporated it.
Granted. Code reduction on the other hand is generally a good thing. :P
I want to say that I would have done the same thing. At the same time though... doing so with a security application assumes that the team supporting the software you depend on is competent enough to properly audit and test their code.
I have a feeling that OpenSSL will be leaving a bad taste in peoples mouths for a while. :/
I want to say that I would have done the same thing. At the same time though... doing so with a security application assumes that the team supporting the software you depend on is competent enough to properly audit and test their code.
I have a feeling that OpenSSL will be leaving a bad taste in peoples mouths for a while. :/
I can see that you have not interacted with Theo before. Sometimes these things are just all personality.
I've not yet had the pleasure, but despite the insight lholden's shared about the contentious relationship between the BSDs, I have a really hard time believing anyone in this industry would be so petty.
Its clear, however, that the only way to get to the bottom of this is to become a big contributor to OpenSSH.
Its clear, however, that the only way to get to the bottom of this is to become a big contributor to OpenSSH.
Dupe.
Previously: https://news.ycombinator.com/item?id=7568059
Previously: 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.
Its really really hard to imagine he is lying.
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.
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.
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.
Dupe of https://news.ycombinator.com/item?id=7568059 and still flag button fodder.
Why would he say that and not reveal the vulnerability ?
Theo is Sloppy Mo: https://www.youtube.com/watch?v=zKvhVssO348
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.