Custom InputControl w/o char->string conversion

[Finn Herpich]

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 at thebuilders.de 
> <mailto:finn at 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
> 


-- 
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