Re: Turning off JIT Optimisation

Discussion in 'Java' started by Mike Schilling, May 15, 2010.

  1. rossum wrote:
    > In a secure program I want to be able to wipe the byte array
    > containing the key, mKey[], before releasing the memory back to the
    > system. To do that I wrote a simple dispose() method to do a
    > reasonably secure overwrite of the array:
    >
    > public void dispose() {
    > if (mKey != null) {
    > for (int i = 0; i < mKey.length; ++i) {
    > for (int j = 0; j < 5; ++j) {
    > mKey = (byte)0x55;
    > mKey = (byte)0xFF;
    > mKey = (byte)0xAA;
    > mKey = (byte)0x00;
    > } // end for
    > } // end for
    > mKey = null;
    > } // end if
    > } // end dispose()
    >
    > Obviously any reasonably good JIT compiler can look at that and
    > optimise it to the equivalent of:
    >
    > public void dispose() {
    > if (mKey != null) {
    > mKey = null;
    > } // end if
    > } // end dispose()
    >
    > That is not what I want, since the repeated overwrites make it more
    > difficult for an attacker to recover the former contents of memory.
    > Is there some way to tell the JIT compiler that I do not want this
    > method to be optimised but to be run as written? Effectively an
    > @Pessimise annotation for just this method.



    I presume you can complicate the logic to where a JIT couldn't optimize all
    of it away:

    public void disposeArray
    {
    // overwrite array
    // add array to global list of disposed objects
    // if the list now has more than 16 members, clear it.
    }

    But I'm curious about

    mKey = (byte)0x55;
    mKey = (byte)0xFF;
    mKey = (byte)0xAA;
    mKey = (byte)0x00;

    Any JIT wirth its salt is going to optimze this to

    mKey = (byte)0x00;

    and why not? I know that overwirting a disk repeatedly with different
    patterns makes ir more difficult to recover the original data, but does this
    really apply to memory?
     
    Mike Schilling, May 15, 2010
    #1
    1. Advertising

  2. Mike Schilling

    markspace Guest

    rossum wrote:
    > IIRC even if you switch the computer off
    > if the attacker cen get its memory chips into a freezer quickly enough
    > the memory may be recoverable for up to 20 minutes.



    This is utterly bogus. There's no way any temperature change short of
    (perhaps) absolute zero is going to have any effect on the minuscule
    charge stored inside a d-ram. No way, no how.

    And I sincerely doubt that "stand-by" retains any information at all,
    unless it swaps memory out to disc.
     
    markspace, May 15, 2010
    #2
    1. Advertising

  3. Mike Schilling

    Arne Vajhøj Guest

    On 15-05-2010 17:42, markspace wrote:
    > rossum wrote:
    >> IIRC even if you switch the computer off
    >> if the attacker cen get its memory chips into a freezer quickly enough
    >> the memory may be recoverable for up to 20 minutes.

    >
    > This is utterly bogus. There's no way any temperature change short of
    > (perhaps) absolute zero is going to have any effect on the minuscule
    > charge stored inside a d-ram. No way, no how.
    >
    > And I sincerely doubt that "stand-by" retains any information at all,
    > unless it swaps memory out to disc.


    http://en.wikipedia.org/wiki/Data_remanence#Data_in_RAM

    I am still not that concerned over it for most usage.

    But if the data contains the code to launch nuclear
    missiles then I vote for better safe than sorry.

    Arne
     
    Arne Vajhøj, May 15, 2010
    #3
  4. In article <hsn4gg$696$-september.org>,
    markspace <> wrote:

    > rossum wrote:
    > > IIRC even if you switch the computer off
    > > if the attacker cen get its memory chips into a freezer quickly enough
    > > the memory may be recoverable for up to 20 minutes.

    >
    >
    > This is utterly bogus. There's no way any temperature change short of
    > (perhaps) absolute zero is going to have any effect on the minuscule
    > charge stored inside a d-ram. No way, no how.
    >
    > And I sincerely doubt that "stand-by" retains any information at all,
    > unless it swaps memory out to disc.


    Freezing DRAM has been proven to work. Some cells do require refreshing
    every few milliseconds but most don't. Spraying the chips with coolant
    slows the data loss enough to move them from one board to another with
    very little loss. You can try this with DRAM video on an old computer.
    Put an image on the screen. Jumper the CPU halt or enable line so the
    system won't crash and reboot. Short the clock that drives the RAM for
    a few seconds. When the clock resumes you'll see most of the image
    return to the screen.

    As for rossum's post, simple wiping can't be done in Java. The JVM
    moves memory periodically to perform heap compaction. A native byte
    buffer will help but it remains a fact that the only way to completely
    secure data is through physical means. Don't let people get their hands
    on the RAM chips.
    --
    I won't see Google Groups replies because I must filter them as spam
     
    Kevin McMurtrie, May 16, 2010
    #4
  5. Mike Schilling

    Lew Guest

    rossum wrote:
    > Security being security you have to assume that the attacker has the
    > latest equipment available. IIRC even if you switch the computer off
    > if the attacker cen get its memory chips into a freezer quickly enough
    > the memory may be recoverable for up to 20 minutes.


    According to what I've read, stick your sticks in liquid N2 and they're
    readable for weeks.

    <http://en.wikipedia.org/wiki/Data_remanence>
    which references
    <http://citp.princeton.edu.nyud.net/pub/coldboot.pdf>

    The Wikipedia article claims that data remains in DRAM for "seconds to minutes
    at room temperature".

    --
    Lew
     
    Lew, May 16, 2010
    #5
  6. Mike Schilling

    Daniel Pitts Guest

    On 5/15/2010 2:42 PM, markspace wrote:
    > rossum wrote:
    >> IIRC even if you switch the computer off
    >> if the attacker cen get its memory chips into a freezer quickly enough
    >> the memory may be recoverable for up to 20 minutes.

    >
    >
    > This is utterly bogus. There's no way any temperature change short of
    > (perhaps) absolute zero is going to have any effect on the minuscule
    > charge stored inside a d-ram. No way, no how.
    >
    > And I sincerely doubt that "stand-by" retains any information at all,
    > unless it swaps memory out to disc.
    >

    Except there has been research into this. Shut-off memory circuits
    state decays slowly enough at room temperature, and even slower if
    blasted by a cold substance (such as turning a can of "canned air" on
    its head). I read about this in a few places, including Communications
    of the ACM. I don't have the exact reference handy though.

    Anyway, memory doesn't decay 100% in mere seconds. The chance of a
    particular cell decaying is small enough that a "hacker" can physically
    retrieve the memory, and easily obtain the information stored in it.

    However, I would assume that simply setting the value to zero would be
    good enough..

    On the other hand, Java provides no way to guarantee that the contents
    of an array are not swapped to disk, or loaded into a different page in
    physically memory. There is nothing you can do from Java (short of JNI)
    to secure that data.
    --
    Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
     
    Daniel Pitts, May 16, 2010
    #6
  7. Daniel Pitts wrote:
    >
    > On the other hand, Java provides no way to guarantee that the contents
    > of an array are not swapped to disk, or loaded into a different page
    > in physically memory. There is nothing you can do from Java (short
    > of JNI) to secure that data.


    JNI is insufficient in any virtual memory system (which is to say, almost
    any modern OS), since the same address in virtual memory might correspond to
    many different physical pages and disk blocks over the course of a program's
    execution.
     
    Mike Schilling, May 16, 2010
    #7
  8. Mike Schilling

    Tom Anderson Guest

    On Sat, 15 May 2010, Mike Schilling wrote:

    > Daniel Pitts wrote:
    >
    >> On the other hand, Java provides no way to guarantee that the contents
    >> of an array are not swapped to disk, or loaded into a different page in
    >> physically memory. There is nothing you can do from Java (short of
    >> JNI) to secure that data.

    >
    > JNI is insufficient in any virtual memory system (which is to say,
    > almost any modern OS), since the same address in virtual memory might
    > correspond to many different physical pages and disk blocks over the
    > course of a program's execution.


    If you take 'JNI' to mean 'JNI used merely to manage a native buffer',
    then yes, but if it means 'JNI used to access the OS's routines for
    managing sensitive data, intended to deal specifically with this
    situation', then no.

    tom

    --
    eviscerated by obfuscation
     
    Tom Anderson, May 16, 2010
    #8
  9. Mike Schilling

    markspace Guest

    Arne Vajhøj wrote:
    > On 15-05-2010 17:42, markspace wrote:
    >> This is utterly bogus. There's no way any temperature change short of
    >> (perhaps) absolute zero is going to have any effect on the minuscule
    >> charge stored inside a d-ram. No way, no how.

    >
    > http://en.wikipedia.org/wiki/Data_remanence#Data_in_RAM



    The Wikipedia cites putting chips in liquid nitrogen, not "in the
    freezer." And if you can do that quickly enough you can just put a
    logic analyzer on the bus and sniff the data directly.

    I can't download the PDF cited. My reader says it's damaged. I still
    think it's hogwash and would require actual physical access to the
    circuit board of a machine. If you're going to transmit keys to the
    client, use a public key. Security through obscurity doesn't work.
     
    markspace, May 16, 2010
    #9
  10. In article <hspb3e$upq$-september.org>,
    markspace <> wrote:

    > > http://en.wikipedia.org/wiki/Data_remanence#Data_in_RAM

    > [...]
    > I can't download the PDF cited. My reader says it's damaged.


    I don't have an Adobe viewer handy; via Safari:

    J. Alex Halderman, et al. "Lest We Remember: Cold Boot Attacks on
    Encryption Keys." <http://citp.princeton.edu.nyud.net/pub/coldboot.pdf>

    "Abstract: Contrary to popular assumption, DRAMs used in most modern
    computers retain their contents for several seconds after power is
    lost, even at room temperature and even if removed from a motherboard..."

    Let me know if I can provide more.

    --
    John B. Matthews
    trashgod at gmail dot com
    <http://sites.google.com/site/drjohnbmatthews>
     
    John B. Matthews, May 16, 2010
    #10
  11. Mike Schilling

    Arne Vajhøj Guest

    On 16-05-2010 13:47, markspace wrote:
    > Arne Vajhøj wrote:
    >> On 15-05-2010 17:42, markspace wrote:
    >>> This is utterly bogus. There's no way any temperature change short of
    >>> (perhaps) absolute zero is going to have any effect on the minuscule
    >>> charge stored inside a d-ram. No way, no how.

    >>
    >> http://en.wikipedia.org/wiki/Data_remanence#Data_in_RAM

    >
    > The Wikipedia cites putting chips in liquid nitrogen, not "in the
    > freezer." And if you can do that quickly enough you can just put a logic
    > analyzer on the bus and sniff the data directly.
    >
    > I can't download the PDF cited. My reader says it's damaged. I still
    > think it's hogwash and would require actual physical access to the
    > circuit board of a machine. If you're going to transmit keys to the
    > client, use a public key. Security through obscurity doesn't work.


    There are serious researchers doing research in this
    and publicizing papers about it.

    How many scientific papers have you written about the
    topic?

    Arne
     
    Arne Vajhøj, May 16, 2010
    #11
  12. Mike Schilling

    Arne Vajhøj Guest

    On 16-05-2010 02:48, Mike Schilling wrote:
    > Daniel Pitts wrote:
    >> On the other hand, Java provides no way to guarantee that the contents
    >> of an array are not swapped to disk, or loaded into a different page
    >> in physically memory. There is nothing you can do from Java (short
    >> of JNI) to secure that data.

    >
    > JNI is insufficient in any virtual memory system (which is to say, almost
    > any modern OS), since the same address in virtual memory might correspond to
    > many different physical pages and disk blocks over the course of a program's
    > execution.


    Most of those modern OS'es also have system calls to lock
    pages in memory.

    Arne
     
    Arne Vajhøj, May 16, 2010
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Santosh

    Turning Off ASPSession Objects

    Santosh, Jun 15, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    520
    George
    Jun 15, 2004
  2. DC Gringo
    Replies:
    2
    Views:
    6,490
    DC Gringo
    Nov 18, 2004
  3. UJ
    Replies:
    1
    Views:
    351
    Kevin Spencer
    Aug 8, 2005
  4. Replies:
    8
    Views:
    6,987
    Gordon Beaton
    Jul 13, 2005
  5. Mike Amling

    Re: Turning off JIT Optimisation

    Mike Amling, May 16, 2010, in forum: Java
    Replies:
    2
    Views:
    388
    Mike Amling
    May 17, 2010
Loading...

Share This Page