<div dir="ltr"><div>Hi,<br></div><div><br></div><div>A simple way to deal with this could be to mark error reporting
steps that potentially display security-sensitive information. See VM::report, STEP macro.</div><div><br></div><div>These steps could print a little prefix/suffix for strippers to do their work.<br></div><div><br></div><div>Cheers, Thomas<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 12, 2023 at 10:13 AM Kevin Walls <<a href="mailto:kevin.walls@oracle.com">kevin.walls@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
8266967: debug.cpp utility find() should print Java Object fields.<br>
<br>
This was providing tooling which brought product builds in line with debug builds for object printing. So what we now see in hs_err was previously limited to debug builds. (Your customers probably weren't running debug builds of course (and that's fine!), so the object details were previously hidden.)<br>
<br>
Escaping Strings in the printer seems worth considering anyway, as a Java String could contain control characters, and yes that will help those who want to process the file. We can think further if anything else needs doing.<br>
<br>
Thanks<br>
Kevin<br>
<br>
<br>
-----Original Message-----<br>
From: Alexandr Miloslavskiy <<a href="mailto:alexandr.miloslavskiy@syntevo.com" target="_blank">alexandr.miloslavskiy@syntevo.com</a>> <br>
Sent: 24 December 2022 13:15<br>
To: <a href="mailto:hotspot-dev@openjdk.java.net" target="_blank">hotspot-dev@openjdk.java.net</a><br>
Cc: <a href="mailto:kevinw@openjdk.org" target="_blank">kevinw@openjdk.org</a>; Marc Strapetz <<a href="mailto:marc.strapetz@syntevo.com" target="_blank">marc.strapetz@syntevo.com</a>><br>
Subject: Potential sensitive information leak through JVM crash logs<br>
<br>
Hello,<br>
<br>
For a quick understanding, consider the following potential hs_err_pid*.log file:<br>
<br>
----------------------------------------<br>
...<br>
stack at sp + 2 slots: 0x00000000c0401098 is an oop: org.x.y.z {0x00000000c0401098} - klass: 'org/x/y/z'<br>
- ---- fields (total size 141 words):<br>
...<br>
- 'x' 'Lorg/a/b/c;' @184 NULL (0)<br>
- 'myPasswordString' 'Ljava/lang/String;' @188 "My password:<br>
correct-horse-battery-staple"{0x00000000c0b01ef0} (c0b01ef0)<br>
- 'y' 'Ljava/lang/String;' @192 "foobar"<br>
...<br>
stack at sp + 3 slots: 0x00007fb06effd7c0 is pointing into the stack for<br>
thread: 0x00007fb0680240f0<br>
...<br>
----------------------------------------<br>
<br>
Here, crash log accidentally exposes a sensitive bit of user's information (the password).<br>
<br>
In our product, when JVM crashes, we ask user to send a crash report.<br>
But users shouldn't be worried that said report may contain something really sensitive.<br>
<br>
For this reason, since we upgraded to JDK that has this feature, we decided to strip these object dumps from the crash log before sending it.<br>
<br>
So far we decided to strip all lines starting from `- ---- fields` until one of<br>
1) `stack at sp + 3 slots` where `+ 3` is exactly 1 more than<br>
previously seen `stack at sp + 2 slots`<br>
2) a line that starts with `R??=` where ?? is any two chars,<br>
to handle registers<br>
3) next section in crash log such as<br>
'Registers:' or<br>
'--------------- P R O C E S S ---------------'.<br>
<br>
It can be seen how it's not convenient and not very reliable to strip due to parsing issues. Especially when a String contains embedded \n, which prevents the easy solution to strip all lines beginning with ` - ` (see example crash log above).<br>
<br>
We propose the following possible solutions:<br>
1) Add some unique marker to begin and end of each object dump, so that everything between the markers can be stripped.<br>
2) Otherwise, ensure that Strings don't span to next line when there's an embedded \n.<br>
<br>
For your reference, a typical crash log can be seen in [1], where object dumps are seen in both sections 'Register to memory mapping:'<br>
'Stack slot to memory mapping:'<br>
<br>
According to my research, the feature of dumping objects in crash logs was (accidentally?) introduced in commit:<br>
5e557d86 by Kevin Walls, 2021-06-08 01:26:13<br>
8266967: debug.cpp utility find() should print Java Object fields.<br>
<br>
[1] <a href="https://bugs.openjdk.org/browse/JDK-8284988" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8284988</a><br>
</blockquote></div>