Language:

en_US

switch to room list switch to menu My folders
Go to page: First ... 36 37 38 39 [40] 41 42 43 44 ... Last
[#] Sat Jun 30 2018 22:10:19 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

Yes ... it seems to be baked into their DNA, right from the beginning when they gave Win16 DLL's their own private execution space that was shared across all programs that were using it.

[#] Mon Jul 02 2018 17:54:42 UTC from kc5tja

[Reply] [ReplyQuoted] [Headers] [Print]

I was under the impression that Win16 was a shared address space environment anyway (e.g., when kicking off an application, you received an instance handle to the previously-and-still-running instance of the same program). That didn't change until Win32. Am I mistaken?

[#] Mon Jul 02 2018 22:21:13 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

Right ... but if two or more different Win16 programs were using the same DLL, the DLL had access to its own address space as well, and it was shared between all of the programs. This made it possible to trick a DLL into leaking data between programs, or at best, crashing all programs that were using it.
I wish Ford were here to explain it; he knew this stuff pretty well.

But of course we know that Win16 wasn't a real operating system anyway. Win16 programs were basically just MS-DOS programs that had access to a rudimentary GUI and some extra libraries.

[#] Fri Jul 06 2018 13:35:37 UTC from fleeb <>

[Reply] [ReplyQuoted] [Headers] [Print]


I think Win16, like, the original Win16, didn't have a concept of multiple users or anything. It expects a single-user environment. When Win32 came along, it created a kind of emulation layer for the Win16 environments that segregated them into different environments.

But...

... because Win32/Win64 have a single kernel, and the way that kernel works, yadda yadda, the different Win16 environments are really only separated by the way memory gets managed, not by the functions that enable this segregation.
So, if you compromise the kernel just so, you could pretty well do heinous things within the different win16 spaces.

Now, I forget how DLLs play into all of this. It feels like there's only ever one DLL in the environment, shared by everyone else, until the last process unloads it, but then, I don't think that's quite accurate, because I recall hooking a dll in one process but not having it hooked in another. OTOH, hooking would just mean for this process, call these functions instead of the DLL functions, so maybe that still makes sense... you'd probably have to figure out how to trick the kernel into interpreting the dlls function locations or something. I forget. It's been a while since I had to know this stuff.

[#] Fri Jul 06 2018 21:28:25 UTC from kc5tja

[Reply] [ReplyQuoted] [Headers] [Print]

Win16, as of Windows 3.0, sat inside a VM, just as DOS VMs did. So while you could compromise KERNEL.EXE or GDI.EXE, you would only end up compromising that Win16 instance. They never used VMMs to enforce protection; but nothing fundamentally *prevented* it from happening.

because Win32/Win64 have a single kernel, and the way that kernel works,
yadda yadda, the different Win16 environments are really only separated by the way memory gets managed

This is as true for Linux as it is for Win16 too. It just takes more work to compromise the system, but it's definitely doable. Both with and without virtualization (easier without, of course). Escalate to root, take control of your target process by way of ptrace, and have all the fun in the world.
Or, take subtle advantage of virtio handlers to break out of your jail, ... viola! A musical instrument!

[#] Mon Jul 09 2018 14:09:58 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

Win16, as of Windows 3.0, sat inside a VM, just as DOS VMs did. So while you could compromise KERNEL.EXE or GDI.EXE, you would only end up compromising that Win16 instance. They never used VMMs to enforce protection; but nothing fundamentally *prevented* it from happening.

The way I remember if was that Windows 3.1 was where they introduced what they called "386 Enhanced" mode, and that's where they started putting each process into a hardware-enforced VM (including legacy MS-DOS programs, which ran in the "DOS box" VM containers available on the 80386).  At that point, a rogue process would throw a protection fault if it tried to access memory outside of its own address space ... at the expense of the operating system no longer being capable of running on an 80286.

I never understood why it was such a big problem for them to solve, when I ran various flavors of unix on 8086 and 80286 based machines for years without having those problems.



[#] Tue Jul 10 2018 12:49:14 UTC from LoanShark <>

[Reply] [ReplyQuoted] [Headers] [Print]


Memory protections were weak to nonexistent even in Windows 3.11 running in 386 Enhanced mode. Features of the 386 processor were used in order to implement virtual memory, but processes could easily write to shared state in DLL's, and I believe another Win16 process's data segment if you had the right pointer.

I believe that basically, the Win16 runtime environment was mapped onto one single 386-mode memory space. Processes in virtual DOS boxes would have had to have their own spaces, but all Win16 processes shared the same space.

[#] Tue Jul 10 2018 12:55:50 UTC from LoanShark <>

[Reply] [ReplyQuoted] [Headers] [Print]


Interesting reminiscing on that: https://blogs.msdn.microsoft.com/oldnewthing/20171113-00/?p=97386

[#] Tue Jul 10 2018 12:58:05 UTC from LoanShark <>

[Reply] [ReplyQuoted] [Headers] [Print]


Old PC Mag article on memory protection: https://goo.gl/ioVdHQ

[#] Tue Jul 10 2018 15:52:06 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

aaaaaaaack ... I forgot about the thunking layer. How horrifying.

[#] Tue Jul 10 2018 18:41:17 UTC from kc5tja

[Reply] [ReplyQuoted] [Headers] [Print]

What LoanShark said about Win16 processes vs DOS processes is what I remember as well; this is why I said earlier that I thought Win16 was a single address space, but Windows 3.0 and later had use VxDs and a VMM to isolate different virtual machines. Win16 was one (shared) VM, while each DOS box was an independent VM.

[#] Wed Jul 11 2018 14:57:36 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

...and Quarterdeck ran circles around Microsoft in every single operating mode. It's too bad M$ didn't acquire that technology in one way or another (either by licensing it or by buying the company). It would have saved a lot of people a lot of pain over the years.

[#] Thu Jul 12 2018 17:14:05 UTC from kc5tja

[Reply] [ReplyQuoted] [Headers] [Print]

Considering MS's history of buying competitors and then shelving the key technologies that they purchased, I am skeptical that that would have helped in any way.

[#] Thu Jul 12 2018 18:04:13 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

Unfortunately you're probably right. I'll just reiterate what I've said many times before about how they should have just stayed the course with Xenix.
All problems would have been solved (including reliably running multiple DOS programs).

[#] Thu Jul 12 2018 22:15:29 UTC from kc5tja

[Reply] [ReplyQuoted] [Headers] [Print]

Yep, I totally agree. Xenix was a great system once. They were fools to ditch it.

[#] Fri Jul 13 2018 13:54:33 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

I think I might have mentioned this before ... many of the features in MS-DOS 2.X were intended to mimic Xenix because their intended long-term migration path at the time was going to be towards Xenix. Then they got distracted by the Mac and went down the OS/2 path, then got greedy and ditched the parts of OS/2 that actually made it work well.

So sad. Xenix would have ruled the world and no one would really have complained much about it.

[#] Fri Jul 13 2018 15:13:59 UTC from Freakdog

[Reply] [ReplyQuoted] [Headers] [Print]

 

Thu Jul 12 2018 18:15:29 EDT from kc5tja @ Uncensored
Yep, I totally agree. Xenix was a great system once. They were fools to ditch it. 

Except for the filesystem...if you didn't properly shut down a Xenix system, the filesystem would unravel like a cheap sweater.



[#] Fri Jul 13 2018 17:41:06 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

The same was true for Linux at one time. Filesystems can be improved or replaced without gutting the whole OS.

[#] Tue Jul 17 2018 16:10:16 UTC from Ragnar Danneskjold

[Reply] [ReplyQuoted] [Headers] [Print]

There is no better file system than NTFS when it comes to survivability of an unexpected shutdown. Which is good, considering how unstable Windows was.

[#] Wed Jul 18 2018 17:29:26 UTC from fleeb <>

[Reply] [ReplyQuoted] [Headers] [Print]


I've heard NTFS described by a developer who worked on a defragger for it as 'slowly unravelling your data over time.'

Go to page: First ... 36 37 38 39 [40] 41 42 43 44 ... Last