Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Qualys Security Advisory – LibreSSL

seclists.org

Post reply on HN
Print view View original

81–89 of 89 posts

Re: Qualys Security Advisory – LibreSSL

#81

Post by msbarnett »

briansmith wrote: post #79
IgorPartola wrote: post #65

Here we go. Another round of "damn it, it's written in C. that's the root of all evil". I think by this point a Markov chain can easily generate responses to the OpenSSL/LibreSSL vulnerability announcements so we don't have to. Yes, C sucks because buffer overflows are still possible. That's by design. At the same time, it goes something like this: 1. OpenSSL (or this time LibreSSL) has a vulnerability discovered. 2.…

> 6. Someone points out that in higher level languages it's hard to write code that is resistant against timing attacks. The discussion dies. This doesn't matter, because the code that should be resistant to timing attacks should be written in assembly language or a language specially designed for that purpose (that doesn't exist yet) anyway. High-level languages have ways of accessing code written in assembly langua…

> This doesn't matter, because the code that should be resistant to timing attacks should be written in assembly language

This would put you right back into buffer overflow territory...

Re: Qualys Security Advisory – LibreSSL

#82

Post by dbaupp »

msbarnett wrote: post #81
briansmith wrote: post #79

Earlier quoted context omitted.

> 6. Someone points out that in higher level languages it's hard to write code that is resistant against timing attacks. The discussion dies. This doesn't matter, because the code that should be resistant to timing attacks should be written in assembly language or a language specially designed for that purpose (that doesn't exist yet) anyway. High-level languages have ways of accessing code written in assembly langua…

> This doesn't matter, because the code that should be resistant to timing attacks should be written in assembly language This would put you right back into buffer overflow territory...

It's unfortunate, but the approach would hopefully be to write the smallest possible primitives in assembly and then use a safer language for the rest of the code that either doesn't need constant time guarantees, or gets those guarantees by building on the primitives. This means that verification against these sort of basic attacks can be focused on a much smaller amount of code, rather than every single location in the whole code-base that manipulates memory (as in C). (And, one can go a step further: extract assembly from some higher-level language/DSL designed to create constant time code.)

In any case, the code in question for this post doesn't seem to be written to be timing sensitive.

Re: Qualys Security Advisory – LibreSSL

#84

Post by Johnny_Brahms »

ised wrote: post #68
Johnny_Brahms wrote: post #32

Earlier quoted context omitted.

I blame C. People that are much smarter than me fail at writing C. I am not even trolling. It is a thought that has been gnawing away at me for some time. I no longer think it's a question of being "good enough" to write good C code. The only one I know of that has written almost bug-free C code is djb, and that code is a fucking pain to look at regardless of what Aaron Schwartz said. It is good, but it is not how an…

"... but it is not how anyone in their right mind writes C." If I were going to place blame (I think a better approach is to skip that and just solve the problem), then I would blame developers, not the language. To me, the code you are criticizing is very "regular" -- it follows predictable patterns. I find it easier to follow than most other C code I read. More importantly I believe it is worth following. Obviously…

I wish all C was written with such care as well. I just wish they had less pointer arithmetic, less one-character variables and was commented, you know, at all...

Re: Qualys Security Advisory – LibreSSL

#85

Post by codygman »

dguido wrote: post #77
IgorPartola wrote: post #65

Here we go. Another round of "damn it, it's written in C. that's the root of all evil". I think by this point a Markov chain can easily generate responses to the OpenSSL/LibreSSL vulnerability announcements so we don't have to. Yes, C sucks because buffer overflows are still possible. That's by design. At the same time, it goes something like this: 1. OpenSSL (or this time LibreSSL) has a vulnerability discovered. 2.…

Don't forget these functional alternatives to OpenSSL: 1. OCaml-TLS ( https://github.com/mirleft/ocaml-tls ) [1] 2. miTLS ( http://www.mitls.org/wsgi/home ) 3. s2n ( https://github.com/awslabs/s2n ) [1] Home of the epic Bitcoin Pinata! http://ownme.ipredator.se/

Don't forget:

https://hackage.haskell.org/package/tls

Re: Qualys Security Advisory – LibreSSL

#86

Post by tptacek »

IgorPartola wrote: post #65

Here we go. Another round of "damn it, it's written in C. that's the root of all evil". I think by this point a Markov chain can easily generate responses to the OpenSSL/LibreSSL vulnerability announcements so we don't have to. Yes, C sucks because buffer overflows are still possible. That's by design. At the same time, it goes something like this: 1. OpenSSL (or this time LibreSSL) has a vulnerability discovered. 2.…

Hey, I'm not anti-unit-testing! I just think a TDD reimplementation of OpenSSL is a silly idea.

Re: Qualys Security Advisory – LibreSSL

#87

Post by richardwhiuk »

glass- wrote: post #42
richardwhiuk wrote: post #38

So much for LibreSSL being a better choice than OpenSSL.

LibreSSL has had roughly half (22 to 43) as many vulnerabilities as OpenSSL since the fork and, before this, 0 sev:high, compared to OpenSSL's 5 sev:high. Would you really disregard all that because of a 1-byte buffer overflow and a memory leak?

False:

CVE-2015-0204 affected LibreSSL, but they thought it was a low priority vulnerability, when it actually is a high priority. They fixed it, didn't notify upstream afaict and just issued a new release.

LibreSSL isn't a panacea, and based on that, they can't even classify vulnerabilities correctly.

Most of the vulnerabilities in OpenSSL are in parts (e.g. DTLS) which are disabled in lots of builds.

Re: Qualys Security Advisory – LibreSSL

#89

Post by 0x01 »

acveilleux wrote: post #73
0x01 wrote: post #51

Earlier quoted context omitted.

Apologies. I should have referenced Lua 5.3 instead as it has both integer and bitwise operator support. This should satisfy the concerns regarding crypto implementation. As for the space considerations, I have two ways to reason this: * Wouldn't it only take up 1x414K? If you create luaSSL as a drop in replacement to OpenSSL, you'd only need one copy in your filesystem, just as you only have one OpenSSL. * Even if y…

For crypto-primitives, you usually want them to be constant-time. This is basically impossible to do in an interpreter or a JIT, indeed optimizing compilers can and will optimize contant-time operations out so inline assembly is commonly used.

Thank you for the info!
Post reply on HN