[Full-Disclosure] Jamming communication [COM] ports in windows...
rgerhards at hq.adiscon.com
Tue Sep 23 15:49:18 BST 2003
> In windows filenames like CON, AUX, PRN, CLOCK$ ,COM* , LPT*
> [ "*" stands for 1, 2, 3, 4 etc... ] can't be created cauz
> it's reserved for "System Device Driver" NAMES by OS itself.
Yes, and don't forget to mention that the file extension does not count.
So COM1.jpg is still serial port 1. ;)
That is by design and - as far as I remember - stems back to CP/M.
Question is if it is smart do still stupport it in the way it is, but
that's another one... It's an publised API we had fun with around 1985,
Please note that there are many legitimate useses for this and removing
it would break a lot of things.
The root issue is that no path is reserved for devices (like /dev in
*nix). Obviously, that wasn't necessary in DOS 1.0 & CP/M as there were
not pathes at all... But with recent advancements made in DOS 2.0 (or
was it 3.0? ;)), it now has become an issue. It might have been clever
to support it in /DEV/COMx only, but this is not done (by design).
Again, many legitimate uses for this... (for example "copy con com1" is
actually often very helpful. As is "echo SomeThingMalicious > COM2" ;-).
> Well, using simple command "say"
> edit COM* [ "*" stands for 1, 2, 3, 4 etc... ]
Its astonishing, though, that Microsoft does not check this on its own
> c:\> edit COM8 < Here COM8 was actually reserved by
> my MODEM in my computer >
> type it in CMD prompt or "RUN" etc... Using this Any/EVERY
> available communication port's in WINDOWS could be JAMMMED!
> By using JUST the privileges of a "GUEST" account.
> The exploits have been successfully tried in Windows xp pro.
> and windows 98. I assume! It works in all versions of
> windows. While trying the exploit THE COM* should not be in use.
I don't have OS/2 at hand, but I think it works there, too. As I wrote,
it of course works on DOS. And /dev/xxx works on *nix ;).
> ---[Background Information]---
> These bug's were originally discovered by hUNT3R, [myself] a
> member of 01 Security Submission. The vendor was notified via email.
Keep it straight: it's not a code bug in Windows. If it is a bug, than
it is a design bug. The bad thing is that there are many applications
out there not doing proper checks. I sent one example last week with the
ZIP file handlers. You send another one today. I quickly tested around
10 applications I had readily at hand, including open source tools. Many
failed. Microsoft office - at least - said "invalid file name (reserved
Bottom line: application developers please be aware that those special
names are around. Of course, this eases porting applications ;)
Full-Disclosure is hosted and sponsored by Secunia.