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

Zeroing buffers is insufficient

daemonology.net

Post reply on HN
Print view View original

81–90 of 134 posts

Re: Zeroing buffers is insufficient

#81

Post by cperciva »

willvarfar wrote: post #5

Excellent point! I really hope such a sensible suggestion is added to mainstream compilers asap and blessed in future standards. Apologies to everyone suffering Mill fatigue, but we've tried to address this not at a language level but a machine level. As mitigation, we have a stack whose rubble you cannot browse, and no ... No registers! But the real strong security comes from the Mill's strong memory protection. It…

Just wondering, have you talked to the CHERI people? It sounds like there is a lot of commonality of interests there.

Re: Zeroing buffers is insufficient

#82

Post by vidarh »

xxs wrote: post #27
Chiba-City wrote: post #18

Please, assembly is OK. It's not even magic or special wizardry. My dad programmed and maintained insurance industry applications in assembly side by side with many other normal office workers for decades. Assembly is OK.

Assembly is not really portable and error prone. I don't consider it anywhere wizardry (or hard) but corner cases are hard in C and in assembly even harder.

In the cases where the alternative is fighting the compiler every step of the way, assembly may very well be less error prone as long as you limit it to exactly the small areas where it will help.

Re: Zeroing buffers is insufficient

#83

Post by lawl »

xxs wrote: post #66
pix64 wrote: post #62

Earlier quoted context omitted.

The point isn't to be faster, it is to be consistent.

That's what I mean actually getting it consistent is hard as the performance is really hard to predict and may change even with CPU stepping. Even then it requires very solid planning as well.

I think you misunderstand timing sidechannels. The idea is that (for example) if you compare two strings with length 15 you compare all 15 chars regardless if you find that the 3th char is already different.

You only need to be consistent with yourself. Stepping is completely irrelevant here.

Re: Zeroing buffers is insufficient

#85

Post by willvarfar »

cperciva wrote: post #81
willvarfar wrote: post #5

Excellent point! I really hope such a sensible suggestion is added to mainstream compilers asap and blessed in future standards. Apologies to everyone suffering Mill fatigue, but we've tried to address this not at a language level but a machine level. As mitigation, we have a stack whose rubble you cannot browse, and no ... No registers! But the real strong security comes from the Mill's strong memory protection. It…

Just wondering, have you talked to the CHERI people? It sounds like there is a lot of commonality of interests there.

I've been following them but we haven't talked. Yet :)

Re: Zeroing buffers is insufficient

#86

Post by tgflynn »

clarry wrote: post #35
erik123 wrote: post #8

It very much looks like a situation in which the system has already been compromised and is running malicious programs that it shouldn't. These malicious programs could still face the hurdle of being held at bay by the permission system that prevents them from reading your key file. However, they could indeed be able to circumvent the permission system by figuring out what sensitive data your program left behind in u…

I'm not sure this is the scenario we're fighting. The problem is when your program (which handles sensitive data) has a flaw in it: for example, it might be possible to trick it into leaking uninitialized data (possibly out of bounds) over the wire. Another potential issue is core dumps (and maybe swapping, but that's a little different). You don't want sensitive data to be written on the disk. Malicious programs run…

What about malicious programs without privileged access ? Is it possible for them to just keep requesting new memory pages from the kernel and see leaked data that was free'd by another process they shouldn't have access to or is this something kernels are already preventing ?

Re: Zeroing buffers is insufficient

#87

Post by AlyssaRowan »

Symmetry wrote: post #75
AlyssaRowan wrote: post #33

Earlier quoted context omitted.

Sadly, I know that only too well: hence my "alas, microcode" comment! A prefix or mode or something which allows code to handle secure data and it gets constant-time multipliers, for example, or true µop-level register zeroisation, would be handy, but also close to unverifiable - we just have to sort of trust it, which sucks. Until then, we do the best we can with turtles all the way down. Software running under that…

There's a fundamental difference between your main memory and your L3 in that the former is DRAM and the later is SRAM. In DRAM you have a charge hidden in a well behind a single transistor and it's designed to be stable for a while (the refresh interval) without anybody doing anything to it. SRAM doesn't have that static component at all, it's a set of 6 or 8 transistors which have two stable configurations when pow…

Yes, SRAM has close-to-zero remanence. But if I were running, say, a Haswell, my L3 might indeed be DRAM (depending on the model).

Saves die space, even with the controller overhead. They love it on SoCs in general, particularly where anything with embedded graphics is concerned.

I'm curious what mechanisms you're talking about. Did you mean physical access? General-purpose processors don't have those (why would they?). Specialised cryptographic SoCs which try to prevent physical attack… well, let's just say for now that results may vary and that if a determined adversary has unlimited physical access to a device, you cannot prevent its compromise.

Re: Zeroing buffers is insufficient

#88

Post by AlyssaRowan »

lazyjones wrote: post #51
AlyssaRowan wrote: post #45

Earlier quoted context omitted.

Having seen a few existing designs of those, up-close and personal - actually they do have to worry about zeroisation, quite an awful lot. And sometimes they don't worry enough either. They ought to fail a FIPS-style audit for that. But, well... they ought not to contain proprietary LFSR "crypto" algorithms, either. They are not as well audited, or as publicly designed, as they ought to be: many are as black-box clos…

Are current GPUs suitable subsystems for running properly isolated cryptographic algorithms? If not, why not? If yes, perhaps a well-audited open source library would be possible.

In the presence of closed-source drivers that manage them and compile the shaders? I'd say probably not. Something open-source with actual direct access to the opcodes (would Mantle work? Intel's embedded GPUs?)… maybe. I don't know if I'd consider them secure. Some running hot and loud and by the seat of their pants? The presence of DMA? Hm. I have my doubts they'd be better than the CPU safety-wise.

What I do know is they can usually run them very fast if asynchronous low-communication parallelisation is not undesirable - GPUs overtook PlayStation 3 Cell processors for the "throw watts at it, but we don't have enough money to burn FPGAs or ASICs" class of crypto attacks quite a few years ago now. (As anyone who runs a Bitcoin mine knows!)

Might be effective on, say, the Raspberry Pi, where the "GPU"'s the ringmaster and the ARM's the clown. That vector processor looks tempting, and if I could figure out how to get it to do diagonals, it's a poster child for ChaCha.

Re: Zeroing buffers is insufficient

#89

Post by xorcist »

willvarfar wrote: post #76
xorcist wrote: post #60

Earlier quoted context omitted.

Why on L4? Is Mill somehow tied to it, architecture-wise? Or is it just that L4 has a smaller footprint and is easier to port?

Its about footprint. We certainly will run Linux on the Mill, but its work we don't have to put on the critical path. L4 is just a familiar lightweight OS, and we're keen to play with Mill-specific security features which are particularly applicable to microkernels too. When we do port Linux, I expect it to become much more microkernel like, as in why would you want your disk drivers to be able to read write video me…

> why would you want your disk drivers to be able to read write video memory etc?

That is a much bigger issue than the CPU architecture, as it has more to do with how the peripheral hardware works (firmware, DMA, etc.), but I appreciate the effort.

Re: Zeroing buffers is insufficient

#90

Post by AlyssaRowan »

tedunangst wrote: post #78
AlyssaRowan wrote: post #43

Earlier quoted context omitted.

As a seasoned and experienced reverse-engineer myself, I'm (genuinely) curious where you got that impression. Do you find it unapproachable? Assembly is the simplest language you can write a computer program in, for a certain very textbook definition of "simple" - it's just that you actually have to do everything by hand that you normally wouldn't. And yes, that can be a pain in the ass, and yes, you do have to watch…

The briar patch of OpenSSL is more in the high level protocol code, and not the asm crypto (the perl obfuscation layer makes it fun, but isn't a major source of bugs). I would not want to write a robust asn.1 parser in assembly. Lots of other cruft works around the presence or absence of various #define values in header files. Rewriting in assembly is not going to solve the problem of deciding how big socklen_t is.

Mm, true: the long grass of the libcrypto part pales in comparison to the thorny nightmare that is the rest of it. Thank you to OpenBSD's LibReSSL for beginning to clear away the worst of the bramble (and uncovering the occasional juicy blackberry in the Valhalla rampage process).

There's a crypto library, and then there's a protocol library. And TLS, to put it politely, has lots of hairy bits, and I hope and pray TLS 1.3 makes a positive impact on that, but I'm not yet sure if it will.

If one were developing from scratch (and I am not) I'd wonder if a reasonable approach would be a ridiculously low-level approach for the primitives, but a ridiculously high-level approach for the protocol. I might consider writing the first in assembly, but the second? If it involved an ASN.1 parser? I would prefer to do something else, anything but that! :-) At the very least, if someone did do it, we'd be able to see exactly how. We just might not want to! I would suggest perhaps instead, maybe something involving formal correctness proofs and then converting those to assembly, because miTLS indicates that this can be an enlightening approach, and seL4 proves that it's possible to actually make use of? (For someone else. I think it is outwith my expertise!)

Post reply on HN