3 ms·

Linden probably deserves the bulk of the blame, but it is a little weird that, if Windows sees a file with an .exe extension that but no PE structure, it will j

Linden probably deserves the bulk of the blame, but it is a little weird that, if Windows sees a file with an .exe extension that but no PE structure, it will just happily take whatever bits it gets and run them directly. But I guess if COM executables genuinely had no structure than there was nothing else that could be done. Yet again, back-compatibility is Microsoft's savior and curse at once.

tedunangst 8y ago
Fortunately this can never happen on linux. The kernel would never interpret a header less executable file as a shell script and invoke it with sh.
- jjnoakes 8y ago
  The Linux kernel won't, but most shells happily will. echo 'ls' > test.sh chmod +x test.sh ./test.sh # Works just fine, no header and since the C library routine "system()" executes the command via /bin/sh, system("./test.sh") works fine too.
danso 8y ago
As much as I want to blame Windows for it, this seems like reasonable behavior if the updater software is passing bytes straight from the HTTP stream. Unfortunate that the 404 page happened to have a byte sequence that would be interpreted as a COM, but the Updater should have been validating the downloaded exe in the first place. Not just for 404 but for actual .exe files that may be malicious
- duskwuff 8y ago
  > Unfortunate that the 404 page happened to have a byte sequence that would be interpreted as a COM That's the thing. Any byte sequence which didn't have an EXE header was interpreted as a COM executable. And in the (NT)VDM environment, there aren't a lot of illegal operations, so executing random data (like an HTML error page) can cause quite a bit of unpredictable behavior before it crashes or gets caught in a loop.
ajross 8y ago
COM files indeed had no structure. DOS would load the file contents to the bottom 64k of memory starting at 0x100, set code, data and stack segments to zero, the stack pointer to zero (so the first push would wrap around to 64k), and jump to 0x100. And that was as much complexity at the linkage had. It's almost hard to remember how easy it was to deal with the hardware back then. We view things as simpler now, but just getting a toolchain installed via rustup or npm or whatever is multiple blog posts of complexity, vs. the paragraph above plus a half-sheet of paper required to scribble down the instruction set and BIOS hooks.
pjc50 8y ago
COM files have no structure; they're loaded directly into a segment and control transferred to the first byte. I think the smallest valid COM file is a single return instruction. Or you can have one file interpreted multiple ways: http://www.nyx.net/~gthompso/poly/polyglot.txt http://www.nyx.net/~gthompso/poly/polyglot.txt

tedunangst 8y ago

Fortunately this can never happen on linux. The kernel would never interpret a header less executable file as a shell script and invoke it with sh.

jjnoakes 8y ago
The Linux kernel won't, but most shells happily will. echo 'ls' > test.sh chmod +x test.sh ./test.sh # Works just fine, no header and since the C library routine "system()" executes the command via /bin/sh, system("./test.sh") works fine too.

danso 8y ago

As much as I want to blame Windows for it, this seems like reasonable behavior if the updater software is passing bytes straight from the HTTP stream. Unfortunate that the 404 page happened to have a byte sequence that would be interpreted as a COM, but the Updater should have been validating the downloaded exe in the first place. Not just for 404 but for actual .exe files that may be malicious

duskwuff 8y ago
> Unfortunate that the 404 page happened to have a byte sequence that would be interpreted as a COM That's the thing. Any byte sequence which didn't have an EXE header was interpreted as a COM executable. And in the (NT)VDM environment, there aren't a lot of illegal operations, so executing random data (like an HTML error page) can cause quite a bit of unpredictable behavior before it crashes or gets caught in a loop.

ajross 8y ago

COM files indeed had no structure. DOS would load the file contents to the bottom 64k of memory starting at 0x100, set code, data and stack segments to zero, the stack pointer to zero (so the first push would wrap around to 64k), and jump to 0x100. And that was as much complexity at the linkage had. It's almost hard to remember how easy it was to deal with the hardware back then. We view things as simpler now, but just getting a toolchain installed via rustup or npm or whatever is multiple blog posts of complexity, vs. the paragraph above plus a half-sheet of paper required to scribble down the instruction set and BIOS hooks.

pjc50 8y ago

COM files have no structure; they're loaded directly into a segment and control transferred to the first byte. I think the smallest valid COM file is a single return instruction. Or you can have one file interpreted multiple ways: http://www.nyx.net/~gthompso/poly/polyglot.txt http://www.nyx.net/~gthompso/poly/polyglot.txt