10

I was researching how old Windows 9x viruses, such as Win95.CIH, got ring 0 access, and it's shown that one of the approaches was to get the Interrupt Descriptor Table, hook the interrupt handler and trigger an exception, so the handler is then executed by kernel in ring 0.

Question is – why was it even allowed by Windows 9x to write in this memory area? Win95.CIH remained a threat for several years, which would have been enough time to patch it, so the best idea I have is that it was one more extremely unsafe compatibility tradeoff, but was it? Wasn't it possible to map these virtual addresses to process-specific memory areas and not run the code from there in ring 0?

Improve this question
7
  • 5
    A ring 3 program could modify autoexec.bat, remember. Its security model was different to XP's.
    – wizzwizz4 ♦
    Jan 6, 2023 at 13:02
  • 5
    Am I suffering a personal deficiency if I want to edit the words 'Interrupt Descriptor Table' into this question somewhere? It just feels off to rely on a reader already knowing the [x86-specific] initialism. But maybe I'm wrong.
    – Tommy
    Jan 6, 2023 at 13:50
  • 4
    @Tommy I make occasional edits to expand specialized initialisms, as was done based on your suggestion. Those edits have always been accepted without comment, here and on other SE sites, so I believe it is generally accepted to do so.
    – Wayne Conrad
    Jan 6, 2023 at 16:38
  • 3
    @Tommy As to whether wanting to explain initialisms is a personal deficiency of yours, I cannot objectively comment, since I am mostly composed of personal deficiencies.
    – Wayne Conrad
    Jan 6, 2023 at 16:41
  • 1
    Why wanted this Virus to run in ring 0 at all? Wasn't it possible to access all resources like files and keyboard input in ring 3?
    – zomega
    Jan 6, 2023 at 21:37

2 Answers 2

Reset to default
4

I was researching how old Windows 9x viruses, such as Win95.CIH, got ring0 access, and it's shown that one of the approaches was to get the IDT, hook the interrupt handler and trigger an exception, so the handler is then executed by kernel in ring 0.

Sure, Win 9x is DOS based and intended to let DOS based software run. Not the least of them being drivers. IIRC only Windows ME changed that for good.

Question is - why was it even allowed by Windows 9x to write in this memory area?

Compatibility. Hooking interrupt vectors is a basic technique for many DOS software. More so the file system wasn't really protected in any way - there was no real user management - as such as well was within the capabilities needed for compatibility.

It's also not only the IDT, but the whole basic data about processes that is handeld in real memory (first MiB).

Wasn't it possible to map these virtual addresses to process-specific memory areas and not run the code from there in ring 0?

Windows 9x was a complete different beast than some ivory tower OS or any of it's follow ups. It is important to note that Win 9x was intended to be the best of all worlds, running DOS applications, Running Windows 3.1 16 bit code and 95's 32 bit code. Only the lateer really uses and benefits from memory protection. all other must give way to application programs to change data like Vector tables or system Memory.

** And it was good the way it was.**

After all, it was that capabilities of running old and new code of Win 9x that made it on one side

  • a great success for Users as they could continue using their old software while enjoying 32 bit as well, while at the same time
  • enabled software companies to create NT compatible software, exactly due creating large user base prior to NT.

Both in combination was what prepared the success XP became.

Improve this answer
4
  • DOS software uses the IVT, not the IDT, which doesn’t even have to be in the first megabyte.
    – Stephen Kitt
    Jan 6, 2023 at 13:24
  • Wasn't the first meg unprotected because of some obscure older-stepping 386 bug? And weren't DOS apps run in virtual 8086 mode with their own memory anyway?
    – Ilia Ershov
    Jan 6, 2023 at 13:26
  • @IliaErshov No, it needed to be shared. Also, as mentioned, DOS drivers were loaded prior (not in ME).
    – Raffzahn
    Jan 6, 2023 at 13:40
  • 6
    I’ll expand my earlier comment: explaining this as supporting DOS compatibility is incorrect. Win95.CIH manipulates the IDT, not the IVT, which is what DOS uses. And DOS code running under Windows manipulates an instanced IVT anyway, not a global IVT; otherwise one DOS VM could crash another. Modifying the IDT is a privileged operation, so Windows 95 had to provide explicit support for unprivileged tasks to modify it; whereas modifying the IVT isn’t.
    – Stephen Kitt
    Jan 6, 2023 at 15:02
1

Windows 9x used protected mode features for stability - stopping most inadvertent programming mistakes from bringing down the system, crashing other programs running, or causing data corruption.

Not all of this protection was even available to non 32 bit applications. Additionally, the OS relied on some 16 bit features to operate, and also implemented some features needed by both 16 and 32 bit applications as shared 16-bit subsystems...

There was never a claim to stopping ALL mistakes, let alone malice. Exhaust the GDI resources? Crash. Hook broken or doctored callbacks into WM_QUERYENDSESSION? Good luck shutting that system down cleanly. Interact with hardware registers directly from a DOS or 16-Bit windows application? God knows what you can do, if s/he has not yet thrown out the old manuals.

Windows NT/2000 was a different beast altogether, doing the opposite: Not compromising on actual security, instead compromising on application backwards compatibility.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .