Re: [GNU Crypto] Passwords Immutable?

[Matthew Sackman]

On Mon, Apr 12, 2004 at 12:44:23PM -0700, Casey Marshall wrote:
> >>>>> "Matthew" == Matthew Sackman <address@hidden> writes:
> Matthew> You can't guarentee that that'll work. A heavily optimised
> Matthew> JVM may well see that the char array is never accessed after
> Matthew> the zeroing so therefore it's unnecessary to execute that
> Matthew> code. At a guess, I think live variable analysis will show
> Matthew> that such code is unnecessary (in terms of the JVM bothering
> Matthew> to execute it).
>
> But still, allowing for the possibility of erasure is, IMHO, a good
> idea. Hoping that someone doesn't optimize all the security out of our
> library is about all we can do ;)

Well yes and no. It is about all you can do but it's dangerous to do it:
  i) You may introduce bugs in doing it.
 ii) You increase code complexity and decrease readability.
iii) You have far more likelihood of very different behaviours on
       different JVMs.
 iv) Other people reading the code may not realise that such code is not
       guarenteed to run and may rely on it - ie you're setting a bad
       example.
  v) Speed sells. A lot of people think that Java has performance issues
       and if you're going to write a JVM then you're going to do well
       if you can advertise it as being the fastest JVM available. Ie
       the optimisations you make to your JVM will affect its market
       penetration and inversely affect the security of programs which
       rely on non-optimising JVMs.

> I think modern languages in general (that I am familiar with, at
> least) don't provide any sort of guarantee on where and how memory is
> allocated.

Having done some OS design work, that's certainly true. It's ultimately
up to how malloc is implemented in the OS though I guess some run time
systems could try to make further guarentees.

> In the context of cryptography it looks like a big
> oversight: we could make bulletproof algorithms and protocols, but
> can't guarantee that the keys themselves will remain secret. It kind
> of comes from an attitude I see everywhere (I call it the SSH notion
> of security): "It's someone else's problem" -- it's hard to make Java
> memory secure, so we pass it off to the C library. It's hard to make C
> memory secure, so we leave it up to the kernel.

Well it's very very difficult. You have all the nice security features
that Java provide: its resistance to buffer overflows, type safety etc
which in general result in more secure programs by default, and yet for
programs which really need to be 'secure' you start getting into
difficulty due to the Java memory model.

For memory attacks you either need full root/administrator access
(provided the OS's security is marginally sane) to be able to read the
memory or you need physical access. I don't really think that in any
language you can really start making effective efforts to safeguard
against those conditions, IMHO.

Besides, right now the majority of security flaws in programs are due to
buffer overflows and as a result we have some funky kernel and userland
code to try to deal with that (grsecurity kernel patches and the C
library Electric Fence come to mind). Until that situation changes, I
don't think it's an effective use of human resources to really push to
get cast-iron guarentees about memory into languages IMHO.

Cheers,

Matthew
--
Matthew Sackman

BOFH excuse #36:
dynamic software linking table corrupted