3 ms·

I don't think it's fair to characterize this as a JRE bug. The only programs that had the opportunity to recognize that the MSI file was signed too early did no

I don't think it's fair to characterize this as a JRE bug. The only programs that had the opportunity to recognize that the MSI file was signed too early did not account for it. The JRE can't be expected to know that Edge and whatever thought the valid JAR it's reading was considered a MSI by the piece of software that processed it, despite being dispatched to the JRE from the explorer.

cpgxiii 6y ago
It's not a bug in the JRE, but the bug is a problem because Windows itself doesn't see the file as dangerous, while the JRE invoked on it treats it as code to execute. Windows, on its own, is not aware that the file represents executable code outside of the validated sections of the MSI.
- 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 ago
    The 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 ago
      To 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 ago
    I 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 ago
      Java applets did actually have their own security model using signatures, which did not necessarily require the host OS to be part of that verification.
- microcolonel 6y ago
  > Windows, on its own, is not aware that the file represents executable code outside of the validated sections of the MSI. I think Windows is aware of this though, it's called JAR and explorer says the JRE should open it. Furthermore, should there be any sections in a signed MSI that aren't signed? Could that serve any legitimate purpose? No, it entirely defeats the purpose of signing it.
  - cpgxiii 6y ago
    Allowing "unreachable" unsigned data to be appended to a MSI isn't really a threat in and of itself, since the data shouldn't be reachable from any of the valid parts of the file. I could easily see some tools appending their own metadata to the end of the file and thus actually relying on such modification not invalidating the signature. I would not be surprised if part of the delay fixing this involved MS finding out early on that a major user of MSI files was actually relying on this (perhaps some installer creation tool or AV scanner?) and decided that the user needed to fix their product and distribute the fixed version before a Windows patch was viable.

cpgxiii 6y ago

It's not a bug in the JRE, but the bug is a problem because Windows itself doesn't see the file as dangerous, while the JRE invoked on it treats it as code to execute. Windows, on its own, is not aware that the file represents executable code outside of the validated sections of the MSI.

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 ago
  The 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 ago
    To 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 ago
  I 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 ago
    Java applets did actually have their own security model using signatures, which did not necessarily require the host OS to be part of that verification.
microcolonel 6y ago
> Windows, on its own, is not aware that the file represents executable code outside of the validated sections of the MSI. I think Windows is aware of this though, it's called JAR and explorer says the JRE should open it. Furthermore, should there be any sections in a signed MSI that aren't signed? Could that serve any legitimate purpose? No, it entirely defeats the purpose of signing it.
- cpgxiii 6y ago
  Allowing "unreachable" unsigned data to be appended to a MSI isn't really a threat in and of itself, since the data shouldn't be reachable from any of the valid parts of the file. I could easily see some tools appending their own metadata to the end of the file and thus actually relying on such modification not invalidating the signature. I would not be surprised if part of the delay fixing this involved MS finding out early on that a major user of MSI files was actually relying on this (perhaps some installer creation tool or AV scanner?) and decided that the user needed to fix their product and distribute the fixed version before a Windows patch was viable.