Hacker News Reader

Comment by morpheuskafka | Hacker News Reader

Perhaps this is one job that shouldn't be remote... those Windows 3.11 boxes shouldn't be anywhere near a network.

Any reason one couldn't connect that machine to a network-accessible KVM switch?

Assuming the KVM switch, and related infrastructure, are well-secured, I don't see how Windows 3.1 vulnerabilities would matter.

(Not sure if the job requires feeding floppies and/or CD's into the machine, which AFAIK isn't something solved by any off-the-shelf KVM switch.)

Few are likely to be connected to the internet, I'd say after perusing https://de.wikipedia.org/wiki/Sibas (German, translation should work).

It seems you can actually order the hardware.

>SIEMENS Sibas 32, 6FH6035-1A + 4x 6FH 9543-3BY60 + 6FH 9533-3BY60 + 6FH 9550-3AY60 + 3x 6FH9485-3A + 6FH9484-3A + 6FH9498-3A + 6FH9481-3B Antriebssteuergerät

7500 EUR, 28 kg (found after a quick search).

I'm always amazed how much some of that Siemens stuff still goes for. My employer had a handful of Siemens PCs ranging from 486 Beetles to Pentium III Scenics in daily use until just a few years ago. They really were built to last.

> Few are likely to be connected to the internet

This is my point, actually.

You wouldn't be directly connecting the PC to the Internet. You'd connect the PC to the KVM switch's PS/2 and VGA connectors. The KVM switch present the corresponding virtual desktop to an appropriate user over the Internet using RDP or similar.

Again, I'm not sure such a product currently exists, but I assume it is, given the needs of data-center admins.

Sibas is the kind of thing you run in a locomotive, not on a PC in some stationary building.

The salespeople probably make jokes about high-speed computers.

Paradoxically, I think it would be very safe because how many remote exploits for Windows 3.11 are out there in the wild?

I don't think Windows 3.11 had any built in networking anyway. It's only network support would have been via dos networking TSR's.

It had a variant "Windows 3.11 for Workgroups" (1993-11), which was the second Microsoft OS with built-in networking, after "Windows 3.1 for Workgroups" (1992-10).

I have actually used "Windows 3.11 for Workgroups" with some coaxial-cable Ethernet NE2000 cards, but I do not remember what network protocols were used.

With all earlier MS-DOS or Windows versions third party networking solutions had to be used.

My first job was at a bank that used Windows 3.11 on all the corporate desktops (late 90s). We had 10mbit ethernet IIRC.

Periodically someone somewhere would plug both ends of an ethernet cable into the wall sockets, causing a broadcast storm and every PC in the building would freeze - Not even the mouse pointer would move.

>Windows 3.11 had any built in networking anyway

*Update:* Yes, looks like it uses the networking stuff provides by MS-DOS.

MS-DOS has NETSTART.BAT and PROTOCOL.INI that initializes TCP/IP with IP address and subnet mask.

When you look how a passenger information system in the trains boots up you can see how it shows BIOS information (floppy drive connected, serial and parallel port available, no harddisks) then it boots MS-DOS, initializes a XMS RAM disk, initializes parallel port, loads Crystal ENDS2ISA ethernet drivers, microsoft DOS TCP/IP protocol driver, and TCP/P MEMM driver, and calls NETBIND.COM.

I suspect most early Windows 3 machines were networked via Novell Netware.

https://en.wikipedia.org/wiki/Novell

Oddly enough my MS-DOS machine while in grad school was networked via a product made by Apple that allowed it to connect to a Mac network. My only use was accessing the department laser printer, but that was huge.

That rings true with my memory, I left the Windows world shortly after 3.11 for Workgroups came out, and there was a lot of Novell around. My job was writing a healthcare information system that used a ISAM database hosted on a Novell server, just starting to investigate SQL.

You could also use packet drivers* with a MS-supplied NDIS shim, as I recall.

* https://en.wikipedia.org/wiki/PC/TCP_Packet_Driver

I wonder does anyone even know how to exploit them anymore? Must be more secure that more recent, but forgotten Linux.

Remote doesn’t necessarily imply using the internet. ;)

As someone else noted, I doubt there's a lot of exploits lurking in hopes that they'll be able to own a Windows 3.11/MS-DOS 6.22 system. I'd be much more concerned about hooking up, say, Windows 7 than Windows 3.11.

I'm not sure it would work on a modern network either.

>Perhaps this is one job that shouldn't be remote..

I guess with some luck you can work on these hardware drivers for Windows 3.11 at home without any access to the network or train. What you need are specifications and maybe some part of the system, maybe there is some simulation software for the internal system of the trains.

I mean the alternative is that you have to work in the train.

*Update:* Since the SIBAS 32 system is just a box someone can sent home to you, you can probably connect a computer with Windows 3.11 to it, and run some simulations on the SIBAS system.

Trumpet Winsock was very slow and barely worked. The exploits for it just made the system crash.

A lot of those crashes are probably running executable code that the attacker hasn't bothered to write yet.

Cooperative multitasking means the chances of pulling anything off without completely crashing or hanging it is slim.

Not really. Once you get it running your exploit payload you can put the required yields in there no problem (or just let it crash after it's finished running your payload). Worst case you might have to be a bit more careful with how you get there (sprinkle some yields in your NOP sled or something), but it's at most a speed bump, not a real countermeasure.

Efficient Windows 3.1 programs are like a giant FSM clockwork where each event loop task is broken into small enough chunks to yield back the processor in a reasonable amount of time. Crafting an exploit that does anything beyond crashing the program or the computer would require knowing how this was done for a particular program.

> Crafting an exploit that does anything beyond crashing the program or the computer would require knowing how this was done for a particular program.

No it doesn't. You can run your exploit code and then crash the program, same as exploiting any other program. Or you can add some minimal code on the end of your exploit payload to exit cleanly. If you really wanted to gold-plate it by having it resume the program where it had been then yes, you'd need to figure out some details, but that's not normal or necessary - classical "smash the stack" style exploiters rarely tried to unsmash the stack afterwards, they'd execute their payload and then exit or crash.

Reply on news.ycombinator.com