Reasons DOSBox is an attractive attack vector:

* Blah blah illusion of containment starting to sound like a broken record.

* Modern virus scanner heuristics look for Windows API calls running in 32/64 bit environments, not for DOS/BIOS API calls running in 16 bit environments. Therefore it is easier to get a malicious program on to the target computer. While an antivirus running on the target system might be able to stop malware once it makes its way from DOSBox on to the host system, there is less of a chance of this happening. The user may not have an background antivirus running at all; they may selectively scan files using run-and-quit scanners or an online scan service.

Fun activity: go to http://www.dcee.net/Files/Antivir/ , download a bunch of DOS viruses, and put a dozen or so in a ZIP file. Go to http://www.virustotal.com, upload it, and watch how many of the antiviruses miss these decades old, well-known viruses. The ones that do detect them do it using definition keys, not heuristics.

* Games. DOSBox is a games platform providing access to a very large library of titles. How does malware spread? Idiot kids downloading infected games. As an added bonus, the IP holders have less interest in pursuing DCMA takedowns than they would with newer titles. The games are ancient and the companies that made them may not even exist anymore.

* People are becoming less familiar with DOS usage than they are with modern operating systems. It would be easier to convince a 12 year-old to do something stupid in DOS ("run this game"), something they've never used before, than something in Windows ("run this .vbs").

* Malware running within DOSBox can access files and the Internet as if it was DOSBox itself. It can evade Windows Firewall, or if a popup does happen, it would show up as DOSBox. A user would be more likely to approve it than a random program they did not know of. An antivirus would be more likely to miss programs downloaded this way than through a browser.

* The fact that DOSBox has never been audited for security. Most popular software available from the Internet is actively checked for security problems, so it's harder to exploit. What better attack vector than a fairly common program that has known problems that are never fixed?

ripsaw8080 wrote:

However, what needs to be considered is how the functionality might be used in existing frontend and menu systems for non-malicious purposes.

Alright, now this is a legitimate argument and one that has me stumped. Maybe a whitelist in the configuration file to permit specific programs to access mounting? It would require anyone using them to retrofit their existing configs, which is a bit of a problem. I'm going to think about it.

You are blowing this way out of proportion... (Btw lock stock Dosbox cannot acces the internet)

Dominus wrote:

You are blowing this way out of proportion

I concede that I'm stating hypothetical points that may be farfetched, but what I'm really getting at is that there is no reason to leave security holes in software if there's an easy fix. "It will break these existing programs" is a rational excuse, "nobody will ever exploit it" isn't.

(lock stock Dosbox cannot acces the internet)

With arbitrary mount access a program can access DOSBox's configuration file. ipx=true and it would, right? The configuration wouldn't be loaded until the next time DOSBox was started, though the program could add itself to the autoexec to ensure it was run again.

Edit: or just run config.com.

Double edit: I just found out about config.com. This is starting to look impossible.

Yep, I'm sunk. If a frontend program is running inside the VM and has whitelisted access to mount/imgmount/config, then all a malicious program has to do is parasite the frontend.

Good game all. I admit defeat.

MadHax wrote:

* Modern virus scanner heuristics look for Windows API calls running in 32/64 bit environments, not for DOS/BIOS API calls running in 16 bit environments. Therefore it is easier to get a malicious program on to the target computer. While an antivirus running on the target system might be able to stop malware once it makes its way from DOSBox on to the host system, there is less of a chance of this happening. The user may not have an background antivirus running at all; they may selectively scan files using run-and-quit scanners or an online scan service.

Except you were mentioning rootkits before. A 16-bit DOS application is not going to be able to magically install a rootkit on its own. At most, a DOS application running in DOSBox will be able to manipulate files on the host – but if it tries to copy a file containing a Win32 virus to an appropriate location, don't you think the virus scanner would recognize the file it is trying to copy?

You might as well say your typical archiving program can be a vector for a virus downloaded in a Zip file.

MadHax wrote:

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

Not to pour oil onto the burning issue, but probably not since DOSBox specifically marks some regions executable. That's how dynamic core works, it interprets emulated instructions, generates native code and runs it on the host. I see no certain way of making sure that some intentionally malicious emulated instruction would not translate to something bad it wants to have done on the host. But IMHO the work (and slowdowns) that would require are not worth it. The basic point is that DOSBox runs user code, either emulated or not, the user needs to know what he's running. There's a reason why Apple does not allow anything that can run user code in the store and signed executables are needed everywhere...

What could be done (and made default?) is some "light"-securemode. Securemode is too strict, it does not allow anything. Having imgmount restricted by default is pointless, since that is sandboxed. Mounting images should be allowed, as well as mounting cd-roms (that's read-only anyway). But plain mount should possibly be restricted somehow by default. There's probably plenty of users that still do 'mount c: c:\'. If not that, a batch file can do it (something like 'mount q: c:\', and 99% user's won't notice the program is writing to their real C:).