4 ms·
It's absolutely a bug in the JRE that it's executable format is a) completely unsigned and b) allows crap at the start of it. If there's a bug in Windows here,
by richardwhiuk 6y ago
It's absolutely a bug in the JRE that it's executable format is a) completely unsigned and b) allows crap at the start of it.
If there's a bug in Windows here, there's a bug in the JRE.
- microcolonel 6y agoThe JRE is a runtime for running arbitrary code, it's the whole purpose of it. If you can put something at the start of a JAR, you can put whatever you want in the JAR. Meanwhile, Windows knows that this will be run by the JRE, because when you open it from the explorer, it is associated with the JRE while the part that validates the file considers it an MSI. Windows is basically completely responsible for this: Windows validates the MSI, windows knows what an MSI is, Windows knows it will be run by the JRE and validates it just as an MSI instead.
- cpgxiii 6y agoTo be fair, all Windows knows that a program, in this case the JRE, is registered to open the file. Nothing about that necessarily means "this file will be executed", nor that that program will interpret the file differently than Windows has.
- stingraycharles 6y agoI disagree, the JRE is a virtual machine; if not for the OS, how would you protect against it? Isn’t the OS itself responsible for authorizing whether the invocation of the JRE process is authorized, rather than the virtual machine itself? Are there any comparable virtual machines that require signed bytecode by default? I’ve personally never heard of it, most of the time it’s verified when the package is downloaded, rather than when it’s executed.
- cpgxiii 6y agoJava applets did actually have their own security model using signatures, which did not necessarily require the host OS to be part of that verification.