It is a security risk but not easily avoided. While you could turn of batch file mounting, one could still add an additional conf file. The autoexec section of that could still automount any folder...

The games you've "wrapped" as examples, are they demos or full commercial versions? The former is probably not a problem, although I think people would be right to be concerned about what kind of Pandora's Box they might be opening; but the latter is not allowed here, in any form.

Dominus wrote:

It is a security risk but not easily avoided. While you could turn of batch file mounting, one could still add an additional conf file. The autoexec section of that could still automount any folder...

Wouldn't that require doing it outside of DOSBox? It would take some major social engineering to get someone to modify their configuration manually -- if you did it with a script or something, you would already be running on the host system and wouldn't have to bother with DOSBox. The devious thing about this exploit is that you have the illusion that DOSBox is a self-contained environment with no access to the host.

ripsaw8080 wrote:

The games you've "wrapped" as examples, are they demos or full commercial versions?

They're *mumble mumble*. I removed them.

Yeah, I don't exactly understand how your thing works, if the batch is run inside or outside of dosbox. Outside of dosbox you can run any config along with the normal one and the autoexec sections of the configs "stack".

Inside of Dosbox you could also run a little exe with the instructions of the batch, so again I'm not sure how one could prevent this except for a huge blacklist of folders to mount...
Thankfully in modern Windows you normally don't have the rights anymore to mess with critical stuff.

I don't want to give any promise this is going to make things 100% secure, but at least there are the -noautoexec and -securemode command line arguments (check the DOSBox README for more details).

EDIT: In addition to -securemode, you can still mount some place with the -c argument, say:

1dosbox -securemode -c "mount d C:\PATH\TO\SOMEFUN"

But you can't mount new paths within DOSBox.

Where's the security vulnerability in this situation? You are requiring the user to *run* something. You don't need all of the fancy obfuscation for that.

The .bat could just about set ACLs and format c:. In any case, DOSBox already contains known vulnerabilities in its handling of certain instructions, which allow it to access OOB memory and potentially run something arbitrary. However, that's not the point.

DOSBox has never been security audited. You play the games, you take your risk. Same as MAME, MESS, and any other emulator.

MadHax wrote:

• x86 code unpacks PKUNZIP and a ZIP archive containing the game to disk (PKUNZIP embedded after the x86 code, the ZIP near the end of the file)[1]

You would almost certainly want to use PKUNZJR.COM, the tiny no-frills version of PKUNZIP.EXE – but I wouldn't be surprised if someone out there hasn't already developed an even tiner version. In fact, for such purposes there's probably someone out there who has made a compression format better than ZIP that requires an even smaller decompression algorithm, but I have no idea what that would be.

There's probably an even more elegant way of doing things – for instance, why not just use a bootable floppy image?

Not new. I've seen this stegonography method used to sneakily transfer roms over a decade ago.

For clarification, the .bat runs inside of DOSBox. This is what I consider to be the security issue; ideally, anything inside of a VM should not be able touch anything on the host system beyond what is strictly needed to emulate the VM environment. If someone runs something malicious outside of DOSBox, sucks to be them, there's nothing you can do about it. Yet if I'm playing Super Mario Bros on a NES emulator, I have a reasonable expectation that mario.nes isn't going to be snooping through my documents.

Dominus wrote:

Inside of Dosbox you could also run a little exe with the instructions of the batch

AFAIK it's not possible to mount anything from an executable. An executable would ultimately have to call command.com (or DOSBox's equivalent) to interpret any batch instructions, which I'm guessing would be exactly the same as running a .bat from the command line.

Dominus wrote:

Thankfully in modern Windows you normally don't have the rights anymore to mess with critical stuff.

It should still be possible to do something like drop a program in the Windows autorun directory, replace common programs with a trojan, change the Internet browsers' homepage, etc. Many people disable Windows UAC because it's annoying.

NY00123 wrote:

-noautoexec and -securemode command line arguments

I'm glad you pointed these out -- I'm going to add securemode to my sandbox configuration. My argument here is pretty much that this option should be turned on by default. Though like you said, it's a pain not being able to mount stuff manually within DOSBox; every CD-based game would require either its own configuration file or having autoexec mount every ISO on startup. Some method of letting the user manually mount stuff while restricting batch files from doing so would be cleaner.

peterferrie wrote:

You are requiring the user to *run* something...set ACLs and format c:

Addressed at the top of this post. I'm drawing a distinction between running something in DOSBox and running something on the host computer. If something running within DOSBox does something malicious, in the worst case scenario it should corrupt the emulated environment, not run rampant on the host system.

DOSBox already contains known vulnerabilities in its handling of certain instructions, which allow it to access OOB memory and potentially run something arbitrary.

Granted, that's a significant security issue. Yet I'd argue that two wrongs don't make a right -- a person with the same knowledge as me, an understanding of how DOS works and basic DOSBox operation, could exploit the issue I've laid out, whereas that same person would not be able to exploit the OOB overrun without specific knowledge of it.

As an aside, wouldn't Windows Data Execution Prevention prevent this?

DOSBox has never been security audited. You play the games, you take your risk.

I can understand your stance here albeit considering it a mildly unfortunate one. If someone installs malware from an abandonware website, whatever happens to their computer is their own fault, right?

Do you hate spam email? I hate spam email. I also hate it when I'm playing a popular online game and it goes down for hours because some skiddie is DDoSing the server because they have a petty vendetta with an Internet celebrity who happens to be playing the game at the same time. It would be trivial for Internet providers to shut down these fiends if it was just their own computer running from their parents' basements, but it isn't. Spam and DDoS attacks are possible thanks to the millions of zombie systems out there. Those computers are zombies because someone in the household downloaded pirated games from the Internet.

Hundreds of thousands of people use DOSBox. Granted there's nothing you can do to stop the spread of malware in the world, but wouldn't you agree that you have a responsibility to ensure your software isn't contributing to the problem?

Jorpho wrote:

would almost certainly want to use PKUNZJR.COM...why not just use a bootable floppy image?

I went with the path of least resistance; my goal was simply to get the game into a PNG, have instructions simple enough for a 4channer to follow in a 250x250 4bpp image and upload it. I used an ancient copy of PKUNZIP because it's what I had laying around; it was only 29KiB. I agree, my methodology was far from the most elegant.

Dosbox just isn't as simple as a condole emulator, not to mention that it doesn't live on piracy like those do.
The only way to make dosbox secure would be to scratch the mount command and only allow imgmount...

I grabbed the source, it looks like it should be an easy fix. Every time a mount is performed, it checks control->SecureMode() and aborts if it's set. So if SecureMode() had a way to see if it's running as the batch interpreter rather than the command line or autoexec, it could always return true. Currently trying to find the divide between the batch interpreter and command line.

edit:
Okay, so...

control.h

1bool SecureMode() const { return secure_mode; }

to

1bool SecureMode() {if(RunningFromBatch)return 1;return secure_mode; }

shell_batch.cpp

1BatchFile::BatchFile(DOS_Shell * host,char const * const resolved_name,char const * const entered_name, char const * const cmd_line) {
2	location = 0;

to

1BatchFile::BatchFile(DOS_Shell * host,char const * const resolved_name,char const * const entered_name, char const * const cmd_line) {
2	RunningFromBatch = 1;
3	location = 0;

shell_batch.cpp

1BatchFile::~BatchFile() {
2	delete cmd;

to

1BatchFile::~BatchFile() {
2	RunningFromBatch = 0;
3	delete cmd;

And then RunningFromBatch defined as a bool somewhere. Wouldn't this work?

That might actually prevent the autoexec from running. Maybe
bool SecureMode() {if(RunningFromBatch&&!first_shell)return 1;return secure_mode; }
instead.

MOUNT is implemented as an external program on the Z: drive, not as a shell command. As such it can be executed as a child program and does not necessarily involve the shell or a batch file (although it can by executed that way as well).

That said, I think the question is not how to code it, it's whether or not it's a good idea to rescind long-standing functionality for such an unlikely pathway to attacking a system.

ripsaw8080 wrote:

MOUNT is implemented as an external program on the Z: drive

Easy fix there...restrict anything that's not the shell from touching Z:\MOUNT.COM or Z:\IMGMOUNT.COM. Ints 13h and 21h are handled internally, right?

ripsaw8080 wrote:

whether or not it's a good idea to rescind long-standing functionality for such an unlikely pathway to attacking a system.

Like I previously mentioned, there is absolutely no reason for legacy programs, what DOSBox is designed to run, to be mounting drives. The only kind of program that would even be aware of their existence would be one that was specifically designed to be run on DOSBox. The likelihood that this would break anything is much lower than someone finding out about this hole and actively exploiting it.

I don't see an issue with it being an optional thing, like a line in the config file saying letmalwareauthorsrootkitme=false. If someone for whatever reason needs to let software mount stuff from within DOSBox, they just change that one line, and everyone's happy.

Alright, let me reframe this issue. Let's forget about about files embedded in PNG files and everything like that and look at a hypothetical scenario.

In our hypothetical scenario, I go black hat and inform the security community that DOSBox has a known vulnerability that can be used to rootkit systems (note that I'm not actually threatening to do that). CoD4EvA, a skiddie, reads about the issue. He creates dosabandonware.com and advertises it at online hangouts for teenage gamers. The website claims that the games can't hurt their computers because they're run from inside an emulator, and virus scanners support the claim because they have no idea how to handle DOS programs. The gamers go to dosabandonware.com, download games, and run them in DOSBox.

Obviously these copies of MechWarrior 2 are infected with malware. The moment the kid types "install" a rootkit goes to town on the machine in the background, while MechWarrior runs in the foreground. The parents' credit card numbers are uploaded and backdoor software is downloaded. The machine is now one of many contributing to spam and DDoS attacks.

Wouldn't you consider this a scenario that has a reasonable chance of happening? Is there really any reason to let it happen, however small the chance may be?

Well, any blocking is best done within the internal code of MOUNT, it covers all possible avenues (e.g. the internal callback instruction) into MOUNT. Such blocking already exists with securemode, so perhaps the simplest approach is to always use securemode. However, what needs to be considered is how the functionality might be used in existing frontend and menu systems for non-malicious purposes.

Well, dosbox doesn't support abandonware, so... 😉

MadHax wrote:

Wouldn't you consider this a scenario that has a reasonable chance of happening? Is there really any reason to let it happen, however small the chance may be?

Why wouldn't the "skiddie" just include the virus as-is? He'd likely lose a big segment of his target audience by expecting them to separately download and configure DOSBox before getting the game running.

There are probably game-console emulators with security flaws in them too.

and virus scanners support the claim because they have no idea how to handle DOS programs.
...
a rootkit goes to town on the machine in the background

Also, these statements appear to be contradictory.

Btw, anyone disabling UAC AND downloading abandonware has it coming anyway.

Yes, Dosbox is not doing this securely, but this whole thing reminds me of the over protection of children these days.
Anyone wanting to spread trojans or malware or virus can do that much more easily AND reaching many more people by other means.