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

51–60 of 89 posts

Re: Qualys Security Advisory – LibreSSL

#51

Post by 0x01 »

masklinn wrote: post #49
0x01 wrote: post #47

Earlier quoted context omitted.

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")

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 you bloat your binary sizes by 414K per executable, isn't it worth it to go from "yes, it could be unsafe, we'll never know... let's wait for the next CVE" to 100% guaranteed no memory faults EVER? Nothing is free, and this could be a cheap price to pay for the guarantee of memory safety, and the implications that come with it.

Edit: wording

Re: Qualys Security Advisory – LibreSSL

#52

Post by fulafel »

masklinn wrote: post #48
fulafel wrote: post #40

Earlier quoted context omitted.

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…

> 2. the callee side must be able to express on-stack by-value structs, many (most?) managed languages don't

I think the FFI could well express this. Just generate a C thunk that converts the value from the stack to a suitable representation.

> 3. and finally the layout (and size) of the struct must be deterministic

The layout and padding of structs is deterministic in all C environments I know of since they end up as part of ABIs.

> 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 make a C FFI call from a safe language to libfoo.so function void foo(char *jsondata) and before the callee returns your safe runtime yanks the data from under it in another thread?

Yeah, you would also need the caller's FFI to guarantee against this to get safety. In absence of such guarantees you should stick to only passing pass-by-value structures!

Re: Qualys Security Advisory – LibreSSL

#53

Post by masklinn »

fulafel wrote: post #52
masklinn wrote: post #48

Earlier quoted context omitted.

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

> 2. the callee side must be able to express on-stack by-value structs, many (most?) managed languages don't I think the FFI could well express this. Just generate a C thunk that converts the value from the stack to a suitable representation. > 3. and finally the layout (and size) of the struct must be deterministic The layout and padding of structs is deterministic in all C environments I know of since they end up a…

> I think the FFI could well express this. Just generate a C thunk that converts the value from the stack to a suitable representation.

Oh definitely, I'm just saying not all of them do (if you follow the link, the Ruby/MRI, CPython and Node FFIs all provide for that at least on the caller side)

> So you make a C FFI call from a safe language to libfoo.so function void foo(char *jsondata) and before the callee returns your safe runtime yanks the data from under it in another thread?

Yup, could happen with a concurrent GC kicking it at an inconvenient time, or with a refcounting GC.

> Yeah, you would also need the FFI to guarantee against this to get safety.

I'm not sure it could (without caller cooperation), best I can see is offer side-channels to "leak" memory (allocate non-managed memory and copy stuff into it) or recommend that you keep an internal strong reference of some sort (e.g. a global list/set).

Re: Qualys Security Advisory – LibreSSL

#54

Post by amalcon »

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…

The nice thing about C has always been how close you can get to the hardware, while still having some sensible flow control. The bad thing about C is how close you need to get to the hardware.

I really think that everyone serious about programming should learn C, to the level where they can read parts of the Linux kernel or something, but never actually deploy C code to a production environment. It's not a "must" -- not a requirement to be a good programmer or developer at all -- but you'll understand something much closer to the hardware than you will in a more modern language. Just don't expose that program to an adversary if you can avoid it, because that proximity to the hardware makes a single mistake catastrophic.

Plus, if you ever need to do embedded work, you often don't have a choice other than C.

Re: Qualys Security Advisory – LibreSSL

#56

Post by curun1r »

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…

Writing C is like handling venomous snakes. There's lots of people that think they can do it safely and, for the most part, they usually do. But if you do it for long enough, you're going to get bitten. All it takes is the smallest mistake. And when that happens, you better hope it's not in the wild, because if left untreated, it gets bad in a hurry.

Rust can't mature fast enough.

Re: Qualys Security Advisory – LibreSSL

#57

Post by diafygi »

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…

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

Re: Qualys Security Advisory – LibreSSL

#58

Post by alricb »

masklinn wrote: post #13
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…

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 use some sort of bignum function if you want to display large arc numbers in decimal. Which is what OpenSSL and LibreSSL do, and that involves creating and destroying BIGNUM objects. The problem is that someone in LibreSSL moved the free() to outside the loop body handling the arc numbers while they were cleaning up. So only the last BIGNUM used gets freed.

Oh, did I tell you that arc numbers are encoded in base 128, with the first bit of every octet used to signal whether it's the last octet of that arc number? Because they are.

Re: Qualys Security Advisory – LibreSSL

#59

Post by ufo »

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…

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

Re: Qualys Security Advisory – LibreSSL

#60

Post by netheril96 »

therealmarv wrote: post #30

OS X 10.11 El Capitan is using LibreSSL: `ssh -V` How I patch this? ;) If anybody has infos when Apple is releasing a fix please tell me.

Install your own LibreSSL with Homebrew or wait for a fix from Apple.

I think Apple never discloses information about security vulnerabilities until a fix is out.

Post reply on HN