Quoting from an Ars Technica article:

'The late '90s were a time before ubiquitous high-speed Internet connectivity, a time when online multiplayer gaming was still something of a novelty. While the Morris worm in 1988 had shown the problems that can arise when insecure code is exposed to hostile networks, it wouldn't be until the early 2000s that the lessons would truly start to be heeded by software developers.

There is no doubt in my mind that the Diablo network code contains bugs, and I would be absolutely astonished if it were free of remotely exploitable bugs. For single player, this is no big deal, because the game is fortunately so old that it doesn't even know how to request a firewall open some ports and allow inbound network traffic. But if you want to use the Battle.net multiplayer mode, you'll have no option but to punch a big hole in your firewall and forward traffic to the game and its inevitably insecure network code.

For modern applications, we have a number of protective systems to make it harder to exploit flawed code. We have different user privileges, so we can run applications as unprivileged user accounts that cannot make extensive modifications to our systems. We have Data Execution Prevention/No Execute/eXecute Disable (DEP/NX/XD; different names for the same thing) that prevents direct execution of malicious code injected by an attacker, and we have Address Space Layout Randomization (ASLR) and Control Flow Guard (CF Guard) to make it harder to trick an application into disabling DEP.

Diablo 1 predates all these measures and is incompatible with them. The application will attempt to elevate itself to have Administrator privileges each time it is run, thereby giving it full access to your system. It does not support DEP or ASLR, and if DEP is forcibly enabled, the game crashes on startup. Nor has it been recompiled to use CF Guard.

As such, running this game and opening up your network to it is going to make it extraordinarily easy to hack your computer. We have built numerous safeguards over the last 15 years to try to reduce the risks of exploitable network code, and this game removes all of them. I would not run it on any system I cared about, and I think it's grossly irresponsible to release it in this condition.'

Those saying it must prove it.
I'm eager to see Mr Peter Bright exposing theses flaws in a technical report and developing a proof of concept about hacking techniques that will be working for this game... #sarcasm.


this article is at best full of confirmation bias

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

Well it is very possible, but of the quoted article at least the NX and ASLR stuff does not apply here. There are things implemented at the OS level, not by the application running. So if you run Diablo 1 on a modern OS (which is the primary purpose of the GOG re-release), then you have all that stuff working.

But apart from that, it is very likely the Diablo 1 multiplayer code is exploitable. But that is also every likely for every other multiplayer game, including modern ones. You won't hear about it, unless somebody has a really big exploitable bug in his net code, because it is not an interesting target for security researchers. Business applications and services and the OS itself are much more interesting targets for researchers, and there are enough exploits to find there. If games would become interesting to research over night, there would probably be a big glut of scary exploits the next morning, and another batch of them every day for some weeks.

But fortunately modern OS mitigations are your friend there, and most hobby hackers that try to exploit your multiplayer game will probably only crash your game at the worst.

Yes and no. Historically, Microsoft has taken a very cautious approach to both these techniques. NX was enabled only for programs that advertised to the OS that their developer wanted NX enabled. They have become more aggressive over time, so NX might be enabled on Diablo for people running up-to-date Windows 10.

ASLR was also initially restricted to programs that opted in. Additionally, ASLR requires the program to be built with relocation information, which most older executables lack. So even if Windows tries to enable ASLR for Diablo, I expect the main program will not be randomized, which will substantially reduce its utility.

Both of those could be fixed relatively easily with a rebuild, but I haven't seen anything suggesting that Blizzard rebuilt Diablo with modern mitigations for this release. I think they just pulled the game out of an archive from back then and released that, bugs and all.

Back when Diablo was popular, there were numerous remote crash bugs and numerous anti-crash cheats. I don't know of any that could run attacker-controlled code, but being remotely crashed while your items were on the ground was quite bad.

Having done years of research into Battle.net games. Including Diablo 1. The Ars article is nothing but spreading FUD. In theory yes, old code that doesn't use the newest and best protections may have issues that those protections protect against.

Diablo isn't the best code wise. And the versions that are shipped by GoG are the original binaries compiled by Blizzard back in 2001. They just edited a few bytes, modified some text files, and added their signatures to the end. This is evidenced by the fact that their 'no-cd patch' is a fairly old one that has been in the community since the game came out. And it's just a nop-out of the cd check function call. Network wise battle.snp, the thing that deals with Battle.net, is identical to vanilla 1.09b. So I think I can say all my experience with the old code is still relevant. Diablo does have some issues related to trusting the server/other client's to much. Thus there are many well known 'exploits' that crash the game. However, code execution wise, there is only one avenue that has been proven to be able to execute code. It requires you to manually connect to someone's malicious Battle.net server {As it's a fundamental part of the update system}. Note: The chat/match making server itself NOT a game server. So people are fine.

Now, I have not delved to deeply into the dx/ipx wrappers. But they look fairly similiar to the ones that have existed in the community for ages. I doubt they do any actual in-memory code manipulation just API hijacking. But I haven't verified so I can't speak for those. But the generic concept of "Old Game with Port forwarding is OBVIOUSLY exploitable" is nonsense. As pcgyver has stated, it is on Ars/Peter to prove his claims. If he does, this will be news, but also easily patch-able.

There are a few other good responses here, but I think it's worth touching on a little more since this seems to be coming up a lot.

In the 90's and early 2000s, development practices were not that great from a security point of view, even with critical software like operating systems. There were a lot of vulnerability classes and categories that weren't well understood then and, as a result, most code from that era is going to likely expose vulnerabilities of varying kinds. We didn't know a whole lot about secure development back then or the risks exposed by insecure software.

The bug type that he mentions in the article is, at a broader level, memory corruption vulnerabilities (buffer overflows, mainly). They were very problematic for a long time and still are, but finding them and exploiting them is a pretty intensive process. It requires that you identify an exploitable vulnerability, then develop a reliable exploit around it (which has a number of requirements in itself and is often more complicated than finding an exploitable bug). Even in older software, it can be a non-trivial process, depending on the context of the bug and requires moderate amounts of reverse engineering.

The mitigations he references (NX, ASLR, etc) were introduced in later versions of Windows, well after Diablo 1, in an attempt to complicate reliable exploitation of these types of issues. They target the second part of what I reference above, the actual exploitation of the vulnerability, which often requires knowledge of where certain things are in memory, the ability to have your own code somewhere, among other things. The operating system introduced means of making exploitation less reliable, so that even if a vulnerability existed, it would be more difficult to exploit and less reliable (resulting in a crash instead of executing the attacker's code). The goal was to make exploitation of these bug classes less reliable, so even though these mitigations don't address the vulnerabilities themselves (so the bug still exists, but it's harder to get what an attacker wants), exploitation attempts would fail. The issue with some of these mitigations is compatibility, which resulted in Windows only enforcing them to varying degrees, which depends on the version of Windows you use. So while Windows may have these mitigations in place, they may not apply to everything running on your computer.

What this means for ANY old piece of software is that there are likely to be memory corruption bugs that are exploitable and the binaries are unlikely to opt in (or will explicitly opt out) to security mitigations. That leaves you with a publicly exposed service that, while Diablo 1 is running, is exposing old, likely vulnerable code with little mitigation that someone could, with the right time investment, leverage to compromise your system 'fairly easily' (relative to what discovering and exploiting those issues looks like today). On the flip side, someone is going to have to really want to mess with you to do that, as no one is really going to want to do it to any kind of scale (e.g. to distribute malware).

Given the amount of work required, even for a trivial bug and no mitigations in place, and the motivation required, I would not be too concerned. That could change if someone publishes a public exploit for the game, but for now, it's not something I'd be overly worried about, certainly not as much as the Ars article seems to lead you to believe.

I will add that I spent some time looking at the network code a few years ago, it's pretty bad in a lot of ways and I have no doubt there are issues there that are exploitable. The question comes down to whether or not someone is going to bother spending the time to do it for such an old game that only a handful of people will have exposed. Maybe someone will publish an exploit for it down the line, who knows, but for now, I'm not overly worried.

It's not. If it is enforced the game crashes on startup - there's a thread in this forum about it, and a support article advising people to disable DEP if they are experiencing crashes (which is lacking details - you need to reboot for the policy change to take effect).

Check task manager when you have Diablo running - go to the processes tab and enable the Data Execution Prevention column, it will not say "enabled" for diablo's process.

As for the game itself being insecure, it is absolutely true - there are many arrays in the game that are statically allocated and it is trivial for another game client to send bad information (item or monster IDs that are beyond the range of expected values) that can cause existing code to be overwritten.

Well first of all there's a big difference between "making our computer remotely exploitable" and "making the game remotely exploitable". Usually, the way a game allows an user to access another user's PC would usually be if the game includes libraries and codes that allow said initial user to send open commands (a.k.a. file directives) to another user. This is actually quite hard and not always possible. Sure, you might be able to modify stuff within the game like stats of monster (if you're the host) and inject codes all around the place, but that would mostly affect data within the specs of the game.

To give an example of an actual game with super big open libraries and open commands over a network: Garry's Mod.
That game is basically one huge open port with, on top, full open command within its own tools. (You can litterally create, fill and launch files from within the game's own public libraries.)

Diablo is kinda like that mixed bag where data between the player is shared in such a simple way that while highly exploitable in terms of in-game effect, it's also just so complex (if not semi-impossible) to actually use the game as a gate to implement any kind of non-standard remote file and/or execution. It's not like you can just send any kind of line of codes through the network and even if you succeed at sending some code through a really inconvenient way, it doesn't mean that the client on the other end includes the ability to read and launch that code.

Yet, there's one possible exploitable that was even exploited in Diablo 2: Camouflaging a form of tool that adds the remote-controls libraries and open commands into another tool such as an character editor or a map revealer. For example, Diablo 2 has a tool called Maphack that was displaying the content of the map instantly and also displayed additional symbols for detecting whatever you wanted. While the original tool was working normally without such thing as bugs, some individual started to take the tool and modified it with either something really bad like a keylogger or even just a series of "drop all your stuff" controlled event.

DevilutionX fixes a lot of the memory issues and also run the games over an encrypted connection, so that should help the situation.