[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: Custom InputControl w/o char->string conversion
From:       David Grieve <david.grieve () oracle ! com>
Date:       2019-03-26 13:35:08
Message-ID: 6f6c60ed-61a0-1b93-9806-f961a557c312 () oracle ! com
[Download RAW message or body]

Have you looked at javax.security.auth.Destroyable?

On 3/26/19 9:07 AM, Finn Herpich wrote:
> Hi Nicolas,
> 
> thanks for the long write up. I'm indeed working with a lot of C# in 
> the last year, but that is a pure accident, to reproduce the 
> SecureString-class was not my intention.
> I'm totally aware of the problems you are listing, but sadly I've to 
> handle sensitive information which force me to reduce the attack 
> surface to a bare minimum for certain values. If an attacker has full 
> access to my process, as you said, it is game over; However I'm trying 
> to reduce the points in time where a value could get leaked to a 
> pagefile or whatever you can think of to be recovered later by memory 
> forensics and such. I know that I'm limit to how the OS handles 
> memory, memory access rights within the system, etc. and I've talked 
> to multiple penetration testers/security analysts in the past few weeks.
> 
> So coming from that requirement I did some tests with char arrays in 
> java which I at least could overwrite quickly enough to minimize the 
> points in time where it could be read and wasn't able to find any 
> traces left in memory (as you also mentioned with the .fill method). 
> However using OpenJFX controls I found my inputs multiple times in 
> memory afterwards, which lead me to the 
> com.sun.javafx.tk.quantum.GlassViewEventHandler class where the input 
> event is converted into a string and I somehow have the impression 
> that it would be some major work to get this out of the event flow for 
> a specialized control.
> 
> In the worst case I've to go back to C++, where it is hard to write 
> secure code, or Rust/Go which don't have such a wonderful and easy 
> deployable cross platform GUI like Java does with openjfx.
> 
> Cheers,
> Finn
> 
> On 26.03.19 12:49, Nicolas Therrien wrote:
> > Hi Finn,
> > 
> > I assume you are coming from a C# background and looking for a 
> > SecureString equivalent in Java.     Check out this:
> > https://github.com/OWASP/passfault/blob/master/core/src/main/java/org/owasp/passfault/impl/SecureString.java \
> >  
> > 
> > You could write your own javafx component with OWASP SecureString and 
> > achieve the same result as in C#.
> > 
> > Hopefully this answers your question.
> > 
> > That being said, what you said about being faster than garbage 
> > collection and again assuming you had SecureString in mind, makes me 
> > think you might not really understand the purpose of SecureString in 
> > C#.   It does NOT guarantee that an attacker would not be able to see 
> > the string if they had access to the application's runtime memory. 
> > Think about it: if you can TYPE your password, there was a byte array 
> > containing your clear text password before it was put in the 
> > SecureString. And then if you can USE that password (during a 
> > database connection), there was a byte array containing your clear 
> > text password when you sent it to the driver. A simple breakpoint in 
> > the right spot and a heap dump would reveal your password, always. 
> > The reason is simple: your application does need to know the password!
> > 
> > The purpose of SecureString is not to protect from being able to 
> > capture the password in memory or from heap dumps. The purpose is to 
> > avoid the password from leaking in log files, console output or in 
> > application messaging. By creating a separate String class extension 
> > for it, the developers made sure that inadvertently calling 
> > "toString()" (as a logger would do) would return some encrypted garbage.
> > 
> > SecureString is a simply a Safeguard against leaking sensitive 
> > strings in logs, console output and application messaging.
> > 
> > If you are still concerned about someone inspecting the heap and look 
> > for the short lived byte arrays containing what you typed, you can 
> > always call .fill(0) on that byte array when you're done with it to 
> > make it harder for the attacker. The OWASP class i shared with you 
> > does that in the constructor. But again, if the attacker has access 
> > to your process, all he has to do is set a breakpoint to the 
> > SecureString constructor and voila, he can read the byte buffer 
> > before its encrypted.   Wiping only makes sure that the original byte 
> > array could not inadvertently be the source of a leak later (ie 
> > someone uses the byte array instead of the string)..That's the real 
> > reason why the OWASP class is wiping the array.
> > 
> > Best regards,
> > 
> > *Nicolas Therrien*
> > 
> > Senior Software Developer
> > 
> > /https://www.motorolasolutions.com/content/dam/msi/images/logos/corporate/msiemailsignature.png/ \
> >  
> > 
> > *o*: +1.819.931.2053
> > 
> > 
> > 
> > On Tue, Mar 26, 2019 at 4:42 AM Finn Herpich <finn@thebuilders.de 
> > <mailto:finn@thebuilders.de>> wrote:
> > 
> > Hi everyone,
> > 
> > I'll hope this is the right place to ask. I'm currently evaluating
> > multiple ways to write a cross platform application with the
> > requirement
> > to be able to clear certain inputs from memory rather quickly and 
> > not
> > wait for the GCs mercy.
> > 
> > I've tracked the JavaFx TextInputControls back to the point where 
> > the
> > character from the input event is transformed into a string. Which
> > happens roughly in com.sun.javafx.tk.quantum.GlassViewEventHandler.
> > 
> > My questions results in, if it would be possible to write a custom
> > control (or some other way) which would leave at least no traces 
> > in the
> > string pool? Right now I've not enough knowledge about JavaFX
> > internals,
> > but it seems like this event handling is implemented way down the
> > rabbit
> > hole and it looks like a major afford to avoid the char->string
> > conversion?
> > 
> > I would be happy about any pointers where to look/start, or if a
> > project
> > like this would be doomed from the start =).
> > 
> > Cheers,
> > Finn
> > 
> > --        Alice and the Builders GmbH
> > Grantham-Allee 2-8, 53757 Sankt Augustin
> > Amtsgericht – Registergericht – Siegburg
> > HRB 13552, Sitz Siegburg
> > Geschäftsführer: Michael Sczepanski, Martin Hensel, Finn Herpich
> > 
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]