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

41–50 of 89 posts

Re: Qualys Security Advisory – LibreSSL

#41

Post by royjacobs »

taspeotis wrote: post #36
riffraff wrote: post #34

Earlier quoted context omitted.

> And when you get into the really high-level languages (Python, Ruby), they simply don't scale. I think you need to qualify what "scale" means in this context. Otherwise java is, for all its warts, more or less as high level as ruby and python, and it's probably been proven to scale up (to big machines, or many developers) reasonably well.

http://martinfowler.com/articles/lmax.html > The system is built on the JVM platform ... in fact they ended up by doing all the business logic for their platform: all trades, from all customers, in all markets - on a single thread. A thread that will process 6 million orders per second using commodity hardware

To be fair, one of the ways they achieved this is by using off-heap memory which needs to be handled in a way similar to how a C allocator would handle it.

Re: Qualys Security Advisory – LibreSSL

#42

Post by glass- »

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?

Re: Qualys Security Advisory – LibreSSL

#43

Post by keeperofdakeys »

Confusion wrote: post #5

So you'd think that if anything, these kinds of 'trivial' bugs, memory leaks and buffer overflows, would not be present in LibreSSL. Especially not in the same function. I wonder what went wrong and how it can be prevented.

Unfortunately code will always have bugs, especially when you are adding or changing it. However the numbers speak for themselves, LibreSSL has been removing large amounts of code http://www.openbsd.org/papers/libtls-fsec-2015/mgp00004.html and has so far had fewer CVEs http://www.openbsd.org/papers/libtls-fsec-2015/mgp00005.html.

Re: Qualys Security Advisory – LibreSSL

#44

Post by Phemist »

quonn wrote: post #10
byuu wrote: post #7

Earlier quoted context omitted.

I know this opinion won't be popular, and I know encryption is a very complex topic, but ... TLS is simply vastly too complicated. How many of us here could write a TLS library even if we wanted to? So you end up with code so complex that even the smartest people can barely understand it, let alone debug it, and you get terrifyingly long CVE lists like for OpenSSL as a result. Compare that to a basic unencrypted HTTP…

> Complexity breeds these kinds of problems as a natural consequence. But the bugs described are not complex - they are local problems that can be understood by just reading one function. The problem here is not complexity, but size (not enough people spend enough time to review all of the code) and the fact that the library is written in a language with manual memory management and unsafe memory access. > I do know…

As far as http+integrity goes: Integrity checks are also based on a shared secret, see https://en.wikipedia.org/wiki/Hash-based_message_authenticat.... So for http+integrity, without the secrecy aspect of TLS, ie the hmac key being public, it would be trivial to generate your own valid integrity hash.

Re: Qualys Security Advisory – LibreSSL

#46

Post by wolf550e »

Phemist wrote: post #44
quonn wrote: post #10

Earlier quoted context omitted.

> Complexity breeds these kinds of problems as a natural consequence. But the bugs described are not complex - they are local problems that can be understood by just reading one function. The problem here is not complexity, but size (not enough people spend enough time to review all of the code) and the fact that the library is written in a language with manual memory management and unsafe memory access. > I do know…

As far as http+integrity goes: Integrity checks are also based on a shared secret, see https://en.wikipedia.org/wiki/Hash-based_message_authenticat... . So for http+integrity, without the secrecy aspect of TLS, ie the hmac key being public, it would be trivial to generate your own valid integrity hash.

Public hmac key is same as posting hash of iso next to the ISO on ftp severs without gpg signature of the hash. No protection at all.

Re: Qualys Security Advisory – LibreSSL

#47

Post by 0x01 »

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…

If we accept that C is here to stay for the time being, but is difficult to manage memory, then why don't we use a mid-way solution?

Lua is built on c, and is much more (than C) memory safe. It retains all the advantages of C (ie, can go anywhere), and we limit the C to 17.3k (as of 5.2.3) lines of c, which is relatively static (won't change, won't bloat in the same way maintaining/building on current C SSL implementations), and could allow us to handle memory safely.

I'm curious why this approach is not used. Portability? Proficiency? Lua is quite possibly the most beautiful language to read. I can't see any downsides, but I'll gladly be enlightened!

Re: Qualys Security Advisory – LibreSSL

#48

Post by masklinn »

fulafel wrote: post #40
masklinn wrote: post #39

Earlier quoted context omitted.

Communicating via the C ABI is as safe as coding in C in the first place. Possibly less as there's a pretty high chance to get the ownership rules wrong on the callee side in a way which'll fault (because the callee will have freed the structure) rather than "just" leak memory (because the caller will not send the structure back for deallocation). Example: https://blog.filippo.io/building-python-modules-with-go-1-5/…

Ownership rules sound a lot like pointers which I excluded. Think pass-by-value structs with only fixed size fields. Or JSON, protobufs etc. (Ok, you need the one pointer for the JSON/PB data, but it's not kept around after null check and decode)

> Think pass-by-value structs with only fixed size fields.

There are (at least) three issues with that:

1. not all FFIs can handle structs, according to the Rust FFI omnibus GHC's doesn't[0]

2. the callee side must be able to express on-stack by-value structs, many (most?) managed languages don't, either not supporting them or having them only as optimisation (based on escape analysis)

3. and finally the layout (and size) of the struct must be deterministic, which further restricts (2)

> Or JSON, protobufs etc. (Ok, you need the one pointer for the JSON/PB data, but it's not kept around after null check and decode)

Depending on the callee's implementation that may be too late already, there is absolutely no guarantee the data will even go through the FFI without being released, so you'd be relying on garbage data not being zeroed/reused/moved in the interval, which would be an implementation detail.

[0] http://jakegoulding.com/rust-ffi-omnibus/tuples/#haskell

Re: Qualys Security Advisory – LibreSSL

#49

Post by masklinn »

0x01 wrote: post #47
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…

If we accept that C is here to stay for the time being, but is difficult to manage memory, then why don't we use a mid-way solution? Lua is built on c, and is much more (than C) memory safe. It retains all the advantages of C (ie, can go anywhere), and we limit the C to 17.3k (as of 5.2.3) lines of c, which is relatively static (won't change, won't bloat in the same way maintaining/building on current C SSL implement…

Well for a start lua not having integers would be an issue when implementing cryptographic primitives. The second issue is while lua is relatively lightweight, carrying a full lua runtime for each of the libraries you're using would still get unwieldy and costly, adding ~400K to each embedder according to the About page ("Under 64-bit Linux, […] the Lua library takes 414K")

Re: Qualys Security Advisory – LibreSSL

#50

Post by Sir_Cmpwn »

0x01 wrote: post #47
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…

If we accept that C is here to stay for the time being, but is difficult to manage memory, then why don't we use a mid-way solution? Lua is built on c, and is much more (than C) memory safe. It retains all the advantages of C (ie, can go anywhere), and we limit the C to 17.3k (as of 5.2.3) lines of c, which is relatively static (won't change, won't bloat in the same way maintaining/building on current C SSL implement…

Speed and ease of using low level techniques, probably.
Post reply on HN