Live data from Hacker News

Undisclosed hole in openssh on FreeBSD and Juniper?

thread.gmane.org

31–40 of 47 posts

Re: Undisclosed hole in openssh on FreeBSD and Juniper?

#31
post #13

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.

> I realize what he meant and that he's right. 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.

Re: Undisclosed hole in openssh on FreeBSD and Juniper?

#32
post #26
post #22

Earlier quoted context omitted.

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)

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'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.

Re: Undisclosed hole in openssh on FreeBSD and Juniper?

#33
post #29

Earlier quoted context omitted.

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.

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.

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. :/

Re: Undisclosed hole in openssh on FreeBSD and Juniper?

#34

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.

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. :)

Re: Undisclosed hole in openssh on FreeBSD and Juniper?

#35
post #31
post #13

Earlier quoted context omitted.

> I realize what he meant and that he's right. 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.

Re: Undisclosed hole in openssh on FreeBSD and Juniper?

#37
post #35
post #31

Earlier quoted context omitted.

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)

Re: Undisclosed hole in openssh on FreeBSD and Juniper?

#38
post #37
post #35

Earlier quoted context omitted.

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…

The original privsep programs weren't async reactor-based designs.

Re: Undisclosed hole in openssh on FreeBSD and Juniper?

#39
post #38
post #37

Earlier quoted context omitted.

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…

The original privsep programs weren't async reactor-based designs.

No they were single threaded forked. Aware of that.

Re: Undisclosed hole in openssh on FreeBSD and Juniper?

#40
post #34

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.

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 me…

What happened next? Did the bug get fixed? Did you do a work-around somehow? Don't leave stories unfinished like this :)
Post reply on HN