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

61–70 of 89 posts

Re: Qualys Security Advisory – LibreSSL

#61

Post by mikegerwitz »

Johnny_Brahms wrote: post #32
kevan wrote: post #2

> These vulnerabilities affect all LibreSSL versions, including LibreSSL 2.0.0 (the first public release) and LibreSSL 2.3.0 (the latest release at the time of writing). OpenSSL is not affected.

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…

Your concerns are legitimate, but I wouldn't jump to blaming C here. Yes, this deals with memory management, but the cost presented is not conceptually difficult. We can rephrase this issue in any other context and not raise a C argument---you have some set of resources that need to be closed (file descriptors, database connections, etc), and you forget to close it. I was writing a daemon in Node.js for my employer and during development I noticed that it leaking file descriptors until the kernel killed it. That can happen in any language.

Nothing against the programmer; these things happen. But I wouldn't say because of C in this case.

Re: Qualys Security Advisory – LibreSSL

#62

Post by masklinn »

alricb wrote: post #58
masklinn wrote: post #13

Earlier quoted context omitted.

Is it TLS specifically or X509 (both by itself and because it uses ASN.1)? I dimly remember X509 and ASN.1 being commonly criticised for their complexity, does TLS pile on additional complexity or just inherit it?

In this case it's definitely ASN.1; the problem is that "objects" are defined with OIDs, which are sequences of integers (called arcs numbers) like { 1 2 840 113549 1 }. The first integer is always 0, 1 or 2, and with 0 or 1, the second is between 0 and 39. But the other integers can be arbitrarily large, and it's important not to overflow: https://www.viathinksoft.de/~daniel-marschall/asn.1/oid_fact... You need to u…

Well these are ASN.1 facts I did not need to know and I would like to not subscribe to that mailing list, but regardless thank you for the explanation.

Re: Qualys Security Advisory – LibreSSL

#63

Post by dbaupp »

mikegerwitz wrote: post #61
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…

Your concerns are legitimate, but I wouldn't jump to blaming C here. Yes, this deals with memory management, but the cost presented is not conceptually difficult. We can rephrase this issue in any other context and not raise a C argument---you have some set of resources that need to be closed (file descriptors, database connections, etc), and you forget to close it. I was writing a daemon in Node.js for my employer a…

C makes these sort of problems more common and occupy more time/energy/source code than they need to. The language doesn't try to help the programmer with even the most basic of these sort of resource management problems. Most modern languages offer tools to handle some subset of them (e.g. GC for memory in managed languages, or destructors for memory and more in C++/Rust), reducing the burden on the programmer for normal resource life cycles and hopefully making it easier to handle the abnormal cases better.

Sure, it's not generally possible for a language to perfectly manage every resource all the time, but this doesn't mean we should just give up and throw away computer assistance in cases when we can have it.

C is an important language, but there's no need to look at it through rose-coloured glasses.

Re: Qualys Security Advisory – LibreSSL

#64

Post by Johnny_Brahms »

ufo wrote: post #59
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…

Could you please summarize how djb's code is different?

Well... Someone said of his code that the only reason it is bug-free is because it scares bugs away. Large amounts of pointer arithmetic. Religious checks (heck, he even checks if printf (not fprintf) succeeds or not), and... odd (not sure if it's the right word. maybe insane is better) macros. Plenty of one letter variables.

Misunderstand me correctly, he writes solid software. He's not just a guy I would like to work with :)

Re: Qualys Security Advisory – LibreSSL

#65

Post by IgorPartola »

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. Everyone gets in an uproar about how we need a clean implementation in a language that prevents stupid errors.

3. Someone suggests unit testing. tptacek tells them to go away.

4. Someone actually points out a Haskell project (https://news.ycombinator.com/item?id=7557089).

5. People poo poo any alternative to OpenSSL because it's not 100% feature complete and besides the best crypto people are already working on OpenSSL so what do these schmucks know?

6. Someone points out that in higher level languages it's hard to write code that is resistant against timing attacks. The discussion dies.

I see only two alternatives. Either as a community we actually stop bike shedding and throw our weight behind a project that might actually become a good alternative to OpenSSL, or we accept that the canonical TLS library will be written in C and have bugs that are periodically discovered and quickly patched.

Re: Qualys Security Advisory – LibreSSL

#66

Post by steveklabnik »

diafygi wrote: post #57
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…

Would Rust be a good alternative? Can you get constant time calculations in Rust?

LLVM isn't great for constant time guarantees, so you need to do the assembly yourself, last I checked.

Re: Qualys Security Advisory – LibreSSL

#67

Post by i80and »

steveklabnik wrote: post #66
diafygi wrote: post #57

Earlier quoted context omitted.

Would Rust be a good alternative? Can you get constant time calculations in Rust?

LLVM isn't great for constant time guarantees, so you need to do the assembly yourself, last I checked.

Well, there is this: https://github.com/klutzy/nadeko

Re: Qualys Security Advisory – LibreSSL

#68

Post by ised »

Johnny_Brahms wrote: post #32
kevan wrote: post #2

> These vulnerabilities affect all LibreSSL versions, including LibreSSL 2.0.0 (the first public release) and LibreSSL 2.3.0 (the latest release at the time of writing). OpenSSL is not affected.

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 he is doing something right as reliability, performance and paucity of bugs shows.

All this despite not being in the "right mind", whatever that means.

I wish all the programs I am forced to use were written with such care.

Re: Qualys Security Advisory – LibreSSL

#69

Post by AUmrysh »

xorcist wrote: post #31
jmnicolas wrote: post #26

I have no knowledge of C, but reading their code I was surprised to see some gotos ... is this OK in C to use goto ?

Most languages use unconditional jumps to break flow when necessary, it might be called "exception" instead of "goto" but it's conceptually the same thing.

In many high level languages a break, continue, pass, that sort of thing (where you want to skip or escape a loop iteration) is usually implemented with a goto as well.

Also, a common use of goto in C is when you're doing something in nested for loops and want to break out of all of them. A goto is actually much cleaner here than using sentinel values or boolean flags, or naughty things like setting your loop variables to be outside of the conditional bounds.

Re: Qualys Security Advisory – LibreSSL

#70

Post by steveklabnik »

i80and wrote: post #67
steveklabnik wrote: post #66

Earlier quoted context omitted.

LLVM isn't great for constant time guarantees, so you need to do the assembly yourself, last I checked.

Well, there is this: https://github.com/klutzy/nadeko

Right. As the README says, LLVM makes this hard. So nadeko handles the codegen itself.
Post reply on HN