Replacement for runFinalizersOnExit()

Thread view:

rossum - 24 Nov 2007 13:48 GMT

I am writing a security related application and I want to make sure
that some critical data is wiped after it is finished with. I have
provided a public dispose() method to do the wiping, and a finalize()
to call dispose in case the user forgets to call it. However,
runFinalizersOnExit() is now deprecated so I cannot be sure that my
finalizer will run at the time the application is exited.

In the absence of runFinalizersOnExit() I am looking for a way to
ensure that the data is wiped before the application exits. Any
suggestions?

Thanks in advance,

rossum

Reply to this Message

Eric Sosman - 24 Nov 2007 14:06 GMT

> I am writing a security related application and I want to make sure
> that some critical data is wiped after it is finished with. I have
[quoted text clipped - 6 lines]
> ensure that the data is wiped before the application exits. Any
> suggestions?

Make sure dispose() is used. You might even go so far
as to set a timer and call dispose() yourself if the user
hasn't called it within T milliseconds.

But I doubt any such mechanism -- not even finalize() --
will be much protection against a determined snoop. After
all, it's not (very) important what was in the process' memory
at the moment it exited, but what's in memory or swap while
the process is running. If the Bad Guy runs your classes in
a JVM which itself is running under a debugger, or even if he
can just cause the JVM to dump core, he's got your data even
if the very next thing you do is wipe it.

Signature

Eric Sosman
esosman@ieee-dot-org.invalid

Reply to this Message

Lew - 24 Nov 2007 16:10 GMT

> Make sure dispose() is used. You might even go so far
> as to set a timer and call dispose() yourself if the user
> hasn't called it within T milliseconds.
>
> But I doubt any such mechanism -- not even finalize() --
> will be much protection against a determined snoop. After

Brian Goetz's essential /Java Concurrency in Practice/ explains that
finalize() immediately puts you into a concurrent-programming situation. He
recommends finally {} blocks. He also refers the reader to
<http://www.hpl.hp.com/personal/Hans_Boehm/misc_slides/java_finalizers.pdf>
for details on how tricky it is to get finalize() right.

Even before runFinalizersOnExit() was deprecated it was already "inherently
unsafe", as the Javadocs describe it.

Use finally {}.

Signature

Lew

Reply to this Message

rossum - 24 Nov 2007 17:07 GMT

>> I am writing a security related application and I want to make sure
>> that some critical data is wiped after it is finished with. I have
[quoted text clipped - 8 lines]
>
> Make sure dispose() is used.

I try. One thought is "It is a sackable offence not to use dispose",
but even then someone is going to slip up somewhere.

>You might even go so far
>as to set a timer and call dispose() yourself if the user
>hasn't called it within T milliseconds.

Probably not practical, but I will have a look at it.

> But I doubt any such mechanism -- not even finalize() --
>will be much protection against a determined snoop.

Agreed, there is no 100% security - all you can do is to make it more
difficult.

>After all, it's not (very) important what was in the process' memory
>at the moment it exited, but what's in memory or swap while
>the process is running.

What is in swap space is not my problem luckily. The OS team are
scratching their heads over that one.

>If the Bad Guy runs your classes in a JVM which itself is running
>under a debugger, or even if he can just cause the JVM to dump
>core, he's got your data even if the very next thing you do is wipe it.

Not my data, his own data. I am talking about wiping things like
passphrases and entropy.

Thaks for the ideas,

rossum

Reply to this Message

Lew - 24 Nov 2007 17:13 GMT

> Not my data, his own data. I am talking about wiping things like
> passphrases and entropy.

I don't know about entropy, but you shouldn't store a passphrase in memory
anyway, even during a program run. The program should forget the passphrase
pretty near immediately.

Signature

Lew

Reply to this Message

Daniel Pitts - 24 Nov 2007 18:23 GMT

>>> I am writing a security related application and I want to make sure
>>> that some critical data is wiped after it is finished with. I have
[quoted text clipped - 9 lines]
> I try. One thought is "It is a sackable offence not to use dispose",
> but even then someone is going to slip up somewhere.

Alternatively, you could "invert" your API a little bit. The only way to
retrieve a secure resource would be to call a method that allocates it,
calls a call-back, and then disposes it:

public void executeSecure(SecureOperation operation) {
SecureResource resource = createResource();
try {
operation.perform(resource);
} finally {
resource.dispose();
}
}

Note, that in the event of a system or application crash, dispose may
never be called.

Also note, that at any time, the used memory could be written to a swap
file. If that happens, it may never get overwritten. Typically,
programs that deal with sensitive data lock their memory so that it
can't be swapped out. I don't think you can do that in Java, so if it is
truly that sensitive, you might need to go into native code.

Signature

Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

Reply to this Message

rossum - 24 Nov 2007 20:42 GMT

>>>> I am writing a security related application and I want to make sure
>>>> that some critical data is wiped after it is finished with. I have
[quoted text clipped - 21 lines]
> }
>}

Good thinking, that will work for some of my interface.

>Note, that in the event of a system or application crash, dispose may
>never be called.
[quoted text clipped - 4 lines]
>can't be swapped out. I don't think you can do that in Java, so if it is
>truly that sensitive, you might need to go into native code.

Luckily, that is a problem for the OS team, not for me :)

Thanks for the suggestion,

rossum

Reply to this Message

Mike Schilling - 24 Nov 2007 15:33 GMT

You can guarantee anything if the application exits abnormally, which is one
of the reasons runFinalizersOnExit() is deprecated.

Reply to this Message

Bent C Dalager - 24 Nov 2007 16:00 GMT

>I am writing a security related application and I want to make sure
>that some critical data is wiped after it is finished with.

If this data is housed outside of the VM, you will probably want an
OS-specific wrapper around the Java invocation to handle this, and
also auto-wipe on OS startup in case the OS crashed and left the data
hanging around the file system.

Cheers,
Bent D

Signature

Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
powered by emacs

Reply to this Message

rossum - 24 Nov 2007 17:09 GMT

>>I am writing a security related application and I want to make sure
>>that some critical data is wiped after it is finished with.
[quoted text clipped - 6 lines]
>Cheers,
> Bent D

OS stuff is for a separate team to deal with. The data is all
internal to the application, such as passphrases and entropy.

rossum

Reply to this Message

David 'Bombe' Roden - 24 Nov 2007 18:29 GMT

> In the absence of runFinalizersOnExit() I am looking for a way to
> ensure that the data is wiped before the application exits. Any
> suggestions?

a) Use char (or byte) arrays and wipe them immediately after using them.
That at least reduces the chance of them being swapped out.
b) Use ShutdownHooks to clear all privacy-relevant data on exit.

> rossum

David

Reply to this Message

rossum - 24 Nov 2007 20:40 GMT

>> In the absence of runFinalizersOnExit() I am looking for a way to
>> ensure that the data is wiped before the application exits. Any
>> suggestions?
>
>a) Use char (or byte) arrays and wipe them immediately after using them.
>That at least reduces the chance of them being swapped out.

I am already doing that where possible.

>b) Use ShutdownHooks to clear all privacy-relevant data on exit.

Excellent suggestion. At first glance it looks like it gives me most
of what I want.

Thanks,

rossum

>> rossum
>
> David

Reply to this Message

Replacement for runFinalizersOnExit()

Free Magazines