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

Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

mathstodon.xyz

Post reply on HN
Print view View original

101–110 of 247 posts

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#101

Post by lazide »

charcircuit wrote: post #98
Twirrim wrote: post #94

Earlier quoted context omitted.

Not sure why you're getting downvoted, this is the entire point of open source. Does such a bug exist in Windows? OSX? Who checks? If someone finds the key in memory, can they tell what conditions might be causing it and where? Their only recourse under those situations is to hand it off to the OS Vendor and trust that what they implement does solve the problem, and trust that it wasn't a deliberate back-door that is…

Security researchers find security bugs in closed source operating systems all of the time.

Yup, it’s just harder to know for sure.

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#102

Post by fsddfsdfssdf »

bbminner wrote: post #75

I am far from a security expert, but from the number of "we missed a single line C check across files during refactoring" critical security bugs discovered on a regular basis these days, the whole premise of a "giant secure open source C codebase" seems questionable. It is not specific to C of course, but invariants are arguably even harder to enforce and track consistently (esp under changes to code) in C. Unsure if…

While I can see the shortcomings of C and generally don't recommend it for new projects I don't see this particular bug as a good example of something Rust's borrow checker or some other language's type system will catch. I don't think even static analyzers can catch this.

It's basically something like this:

original: DoTheThing()

new: DoTheThingSlightlyDifferentButKeepMyCredentialsAlive()

fix: DoTheThingSlightlyDifferentButDoInFactNOTKeepMyCredentialsAlive()

In my experience a substantial portion of gnarly bugs come down to a violation of a high-level system invariant and those do not strike me as something that can be automated. Even with something like Lean you can prove your program satisfies certain properties but you need to have thought about those properties in the first place. The proof doesn't discover the invariant for you.

If you'd had thought about the relevant security property you could have written a regression test for it which is not hard. IMO the really hard part isn't expressing the implementation safely, but it's the realization that this was a property the implementation needed to preserve.

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#103

Post by tombert »

I don't think this bothers me.

The only reason that I do the disk encryption is so that I don't have to worry about people going through my laptop to steal tax documents and/or credit card stuff when I sell the laptop. I of course also wipe the laptop too, but I figure that if the data is encrypted at the drive level then there's very little risk of anyone being able to use some kind of forensics tool and recover data.

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#104

Post by quotemstr »

It's because of vulnerabilities like this that I enable Intel's "total memory encryption" feature. No plaintext leaves the CPU package. DIMM swap attacks become useless. Moreover, it's basically free: the cryptography happens directly in the memory controller, in hardware, inline with the bus transactions the CPU is doing anyway.

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#105

Post by pixl97 »

WhitneyLand wrote: post #99
bbminner wrote: post #75

I am far from a security expert, but from the number of "we missed a single line C check across files during refactoring" critical security bugs discovered on a regular basis these days, the whole premise of a "giant secure open source C codebase" seems questionable. It is not specific to C of course, but invariants are arguably even harder to enforce and track consistently (esp under changes to code) in C. Unsure if…

The premise of a secure open codebase is fine. The problem is being more auditable does not automatically make it more audited. There have to be enough people with skill taking enough time to work on it.

If you think open source is bad, wait till you see enterprise code. I'm talking full auth bypass due to the stupidest crap. You can do that in any language if you have fools working on the code base.

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#106

Post by pixl97 »

lazide wrote: post #101
charcircuit wrote: post #98

Earlier quoted context omitted.

Security researchers find security bugs in closed source operating systems all of the time.

Yup, it’s just harder to know for sure.

Oh, and large companies quite often fix these horrific issues silently, especially in online services where the customer can't diff bins. We're talking auth bypasses and RCE's that you'll never know about.

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#107

Post by fsddfsdfssdf »

russdill wrote: post #100
bbminner wrote: post #75

I am far from a security expert, but from the number of "we missed a single line C check across files during refactoring" critical security bugs discovered on a regular basis these days, the whole premise of a "giant secure open source C codebase" seems questionable. It is not specific to C of course, but invariants are arguably even harder to enforce and track consistently (esp under changes to code) in C. Unsure if…

The lesson here is that if a feature (at a minimum) does not have a associated test case, it is not actually a feature.

Yes, I agree. I find the addition of the regression test the true long-term fix. The code is just an opaque incantation that may or may not preserve some property we find worth preserving and we have no way of knowing it keeps preserving it over time as other parts of the system change.

The test actually proves it and while it too can change it has more staying power because it's expressed at a higher level of abstraction ("random arcane weird C shit" in the case of code versus "does this property hold" in the case of a regression test).

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#108

Post by danudey »

pixl97 wrote: post #105
WhitneyLand wrote: post #99

Earlier quoted context omitted.

The premise of a secure open codebase is fine. The problem is being more auditable does not automatically make it more audited. There have to be enough people with skill taking enough time to work on it.

If you think open source is bad, wait till you see enterprise code. I'm talking full auth bypass due to the stupidest crap. You can do that in any language if you have fools working on the code base.

Even security code. Fortinet, a vendor whose entire thing is security for your network, is consistently getting caught out with default passwords, backdoors, etc.

https://community.spiceworks.com/t/hard-coded-password-backd...

This sort of thing leads to every kind of exploit, like

https://www.linkedin.com/pulse/half-worlds-fortinet-firewall...

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#109

Post by 620gelato »

pixl97 wrote: post #105
WhitneyLand wrote: post #99

Earlier quoted context omitted.

The premise of a secure open codebase is fine. The problem is being more auditable does not automatically make it more audited. There have to be enough people with skill taking enough time to work on it.

If you think open source is bad, wait till you see enterprise code. I'm talking full auth bypass due to the stupidest crap. You can do that in any language if you have fools working on the code base.

I explicitly make sure services I lead have Integration tests in CI pipeline to validate the "negative paths" against all APIs with missing, invalid, un-authorised identities, expired, un-authenticated tokens. Of course that still doesn't cover every surface, but even that gets sideways glances from some folks who think we should just test happy paths and why we're testing for access controls in Integration tests.

Re: Since Linux 6.9, LUKS suspend stopped wiping disk-encryption keys from memory

#110

Post by deepsun »

bbminner wrote: post #75

I am far from a security expert, but from the number of "we missed a single line C check across files during refactoring" critical security bugs discovered on a regular basis these days, the whole premise of a "giant secure open source C codebase" seems questionable. It is not specific to C of course, but invariants are arguably even harder to enforce and track consistently (esp under changes to code) in C. Unsure if…

"Million eyeballs" argument was always kinda meh.
Post reply on HN