JDK-8172932 : JRE installation fails with 1603 on Windows 10 with enabled Deviceguard
  • Type: Bug
  • Component: install
  • Sub-Component: install
  • Affected Version: 8u112,9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: other
  • CPU: x86
  • Submitted: 2017-01-12
  • Updated: 2017-05-04
  • Resolved: 2017-03-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u131Fixed 9 b160Fixed
Description
FULL PRODUCT VERSION :
Can not provide becaus installation is not possible 

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 10.0.14393]

EXTRA RELEVANT SYSTEM CONFIGURATION :
X64 and Microsoft Deviceguard is enabled on the Client

A DESCRIPTION OF THE PROBLEM :
Hi, 
��
Installation of JRE on Windows 10 with enabled Device Guard is not working.
��
If Device Guard is in audit mode or in enforcement mode on Windows 10, the JRE installation breaks with 1603.
��
Reason is a file called bspatch.exe used by JRE installer to merge Files.
��
This file has an wrong PE header, and Device guard cannot verify the Hash, so the execution is blocked with an access denied.
��
Solution is to compile bspatch.exe as part of the JRE installer with an correct PE header, and implement the fixed file in your JRE installer.
��
This Bug in the JRE installer will affect all Company���s using Windows 10 with Microsoft Device guard enabled to secure the client. No one will be able to install or patch JRE on their clients until this File is fixed within the installer of JRE.
��
Currently the only solution is to dissable Deviceguard, what is not an Option in this case, because we like to have an secure Client !
��
Currently there are two tickets running. One by MS and one by Oracle.
Dear Support feel free to contact me, to get more information to the 2 tickets and the technical background.
��
This Thrad has more or les the same topic, bspatch.exe get marked as Malware because the PE headder is wrong... JRE/SDK 1603 error, potential solution 

And i wrote the same in an own Thread
https://community.oracle.com/message/14181819#14181819��

In the Oracle Ticket SR 3-13830236201 there is all the information how to reproduce the issue, as well as a zip File with information���s for reproduce.

Maybe your TSAnet (www.tsanet.org) Members could get in contact with TSAnet members of Microsoft to get in touch about the details.
��
Pleas fix this soon , i promis Oracle that you get contacted by other Companys who like to enable DG on Windows 10 Clients to have an Secure Client in future!
And as you shuld know Security is first !
��
regards
Paul

REGRESSION.  Last worked in version 8u111

ADDITIONAL REGRESSION INFORMATION: 
Every 7,8 and 9 version is efected

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Enable Deviceguard in Audit mode on Windows 10

pleas have a look at the Ticket SR 3-13830236201 there is an How to reproduce


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
JRE should be installed
ACTUAL -
Java installation Fails becaus BSPATCH.EXE is Blocked from Deviceguard

ERROR MESSAGES/STACK TRACES THAT OCCUR :
1603 / Access denied during Execution of BSPATCH.EXE

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
pleas have a look at the Ticket SR 3-13830236201 there is an How to reproduce

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Dissable Deviceguard, this is not an Solution!
Comments
Verified with JDK9 b166
04-05-2017
No need to run in a AU mode to reprouduce issue. To reproduce, 1. in a clean machine with DeviceGuard enabled. 2. run the jre.exe and it should throw 1603 with "system error 5 (Access is denied)" in jusched.log
07-03-2017
CPU17_02-critical-request justification: - Fix for Release : 8u131 - Justification : low-risk, required to address blocked installation on any host running DeviceGuard - Risk Analysis : low - same revision of of binary is used, just in uncompressed format, instead of self-extracting compressed - Webrev : NA - binary update only on the build host (9 has associate changes for JIB that do not apply to 8) - Testing (done/to-be-done) : 9 PIT/8u- promotion - Back ports (done/to-be-done) : dev build machines (JPRT) already updated, this CR tracks RE/promoted envs - FX Impact : NA Note: please see JDK-8174221 for actual infra changes required
02-03-2017
URL: http://closedjdk.us.oracle.com/jdk9/client/install/rev/9b3285d20024 User: billyh Date: 2017-02-15 21:13:30 +0000
02-03-2017
A note about test coverage - this issue was not found with conventional testing because it is an extreme corner case involving additional third party software running on the system. In house virtual machines from PDIT and created by SQE were not able to be set up correctly due to their nature and actual hardware had to be used. Even then it was hard to repro but with diligent effort by multiple test people we were able to get something to the dev team to analyze.
16-02-2017
This issue will be resolved with updated bspatch via JDK-8174221.
13-02-2017
I tried to compress uncompressed bspatch.exe with the latest upx v3.93. It produces exactly the same binary with corrupted PE headers.
07-02-2017
I agree that using upx -d to uncompress the bspatch is the correct solution. It's not like we are really getting anything out of the bspatch upx compression. So the fix is to to update our build machines with the new bspatch.exe Keep in mind the bspatch.exe file was built back in 2005, so it's likely using a very old version of UPX. It does not look our version of UPX has this issue, so we don't necessarily have to stop using it on our iftw exe's.
07-02-2017
http://webbugs.us.oracle.com:9090/bugreports/JDK-8172932/BugDetails-ReproducerSteps.pdf : --- 3 conclusion here : - Bspatch is reporting to the OS a larger code size than the real size. - Signing the file raise the filesize to a sufficient amount of bytes so that when Windows computes (fileSize ��� hashedBytes), it ends with a positive result - Regarding bspatch, the real issue is all about file/section size and has nothing to deal with certificates. Signing the file seems to solve the issue because it adds bytes to the file. To confirm the real workaround is just to add bytes and not to sign the file, I editied bspatch.exe with VisualStudio and added 0x00 bytes to that filesize comes > 38 400 --- bspatch.exe we use is compressed with upx. upx compressor produces wrong data in PE headers. I unpacked bspatch.exe using 'upx.exe -d' command and unpacked bspatch.exe runs just fine on Win10 with Device Guard enabled. So the solution is just to unpack existing bspatch.exe with 'upx.exe -d' command. Side note: we should probably stop using upx compression with online wrappers if upx produces wrong data in PE headers for them.
07-02-2017
Lowest impact solution is to rebuilt bspatch to resolve the PE header, without introducing dependencies or additional licensing requirements. Dev team is determining feasibility of the latter.
06-02-2017
bapatch.zip - bspatch.exe with prerequisite dlls from Cygwin installation on my laptop.
30-01-2017
bsdiff is standard Unix utility, so it is part of Cygwin. The quick fix is just pick up bsdiff from your Cygwin install. Mine attached with all prerequisite dll-s. Please try running bspatch.exe standalone on the box where JRE installation fails. Bill confirmed that Cygwin's bspatch.exe works fine on the box where problem is reproducible. Integration of Cygwin's executable in JRE installer might not be feasible due to licensing restrictions. If this is the case, we can try fix PE header of original bspatch.exe. I'd say that this is in fact the preferable way to fix the issue. However I'm not expert in this area, but I strongly believe this should be possible. Just need to find the right tools to manipulate PE header.
30-01-2017
Must-fix issue for 17_02. Dev investigating if the issue can be addressed by MS, in lieu of adding new build dependencies and maintenance of bspatch.exe src.
23-01-2017
bspatch.exe is part of the bsdiff 3rd party tool that we use to create binary patches for smaller updates for the JRE. http://www.daemonology.net/bsdiff/ The bspatch.exe executable is something that we simply bundle up and use during runtime...and then delete. We do not build this executable ourselves. I think we need to communicate to Microsoft/DeviceGuard team to allow this file to run.
18-01-2017