Gah! Need better anti-bug stuff

**Tellos Athenaios** · 12-07-2009, 16:49

Originally Posted by Sevis

The fact they are container formats - and thus they are supposed to contain arbitrary data - is a reason to consider them safe. They are not supposed to be executed under any conditions. A viewer that runs any sort of script from a .gif is highly insecure and should not be used, period.

Actually the container formats often do contain arbitrary code (DVD menu's are scripts) or can serve as attack vector for such (MP3's can trigger download of ‘album art’ and such). In fact this is why Microsoft Office documents can be a potential risk: these too are container formats and can play ‘host’ to VB script.

The problem with the GIF is that it's data format is pretty much the same as an ASCII text file. So is a batch script. Windows trusts that what you download is a GIF file. Perhaps unfounded...

I didn't know about the NTFS data streams (and I still see very little point in such a function),

The point probably was/is that you can attach meta data to a file stream. But anyways...

but what would trigger those streams? Are they opened at the same time as the main file (in which case, they can do as much damage as the file itself - thus, in the case of a .dll or .exe, lots, but none as a plain text), or must they be called separately? And, if they must indeed be called separately, what would call them on a freshly installed system?

... As I said the streams can be specifically opened. The problem is not *that* there are streams; but the problem is that by default Windows has a laissez-faire attitude towards what is executable and what is not; which is why the batch script as GIF file trick works in the first place (e.g. try to execute your average GIF file under a Unix environment and you will probably find it complains about not being permitted to execute the file).

Now about the streams they can be specifically looked up by a program (and modern [decent] AV kit should scan for streams). The reason why DLL files in particular are a danger is that they tend to be loaded early and by ‘trusted’ programs. E.g. your Microsoft Office will load riched.dll (a library for the Office rich text editor), so any malware that wants to load its main (malevolent) payload would simply attempt to inject this into such a DLL file. Now its payload can be effectively obscured because the malware can simply wait until Word, Excel or similar is loaded.

The ‘classic’ example of this would be the User32.dll file which is loaded during log-on since it contains user-account handling code. Again AV makers learned this lessons the hard way in the early days of NTFS.

EDIT: And would copying the files over to the tmpfs, before moving them over to a FAT32 not get rid of these streams? Does FAT32 even support them?

Streams are not supported by FAT32 but you may simply end up with a bunch of files if you try to copy an NTFS file that contains more than just 1 stream: I am not sure, I've never had a reason to try that.

At any rate we are veering off into the realm of the academical arguments. My point is that you cannot trust a file based on (false) assumptions on the file type.

**Sevis** · 12-07-2009, 17:36

To review my original description:

Safe:

.jpg
.jpeg
.png
.gif
.mp3
.ogg
.mp4
.wma
.avi
.mkv
.pdf (?)

Unsafe:

.doc
.xls
.ppt
.exe

I haven't considered the album-art download script. Whether those can be dangerous is a good question - are they really file-side? I was assuming the player searched using the meta-data available within a trusted resource... MS Office documents, I most certainly agree, should not be copied. As to DVD-menus - I don't remember any of the file types I listed supporting it. WMA and MP4, maybe? Never liked those...

The problem with the GIF is that it's data format is pretty much the same as an ASCII text file. So is a batch script. Windows trusts that what you download is a GIF file. Perhaps unfounded...

I'll test this later (giving an executable a .gif extension) - do you perhaps mean the hidden extension "feature" in Explorer? Whoever thought that thing up deserves no compassion.

The problem is not *that* there are streams; but the problem is that by default Windows has a laissez-faire attitude towards what is executable and what is not;

The reason why DLL files in particular are a danger is that they tend to be loaded early and by ‘trusted’ programs. E.g. your Microsoft Office will load riched.dll (a library for the Office rich text editor), so any malware that wants to load its main (malevolent) payload would simply attempt to inject this into such a DLL file.

I didn't mention .dll files due to those being unnecessary for an average user to transfer between computers, but they certainly fall in the same category. However, if I understand this correctly, the injection would have to be in the main file (riched.dll, not riched.dll:malware.dll), making streams irrelevant to that specific case.

Also, I looked it up, and copying a stream over to a filesystem that does not support it (or generally doing anything with it with a program that is unaware of it) will destroy it.

At any rate we are veering off into the realm of the academical arguments. My point is that you cannot trust a file based on (false) assumptions on the file type.

Indeed we have, but I truly am curious how wrong my advice was. To adjust it, Beirut: Make sure that the files you copy contain what you expect them to contain (are valid images, music, etc.) and that their extension really is what you expect it to be. If you're unsure, Linux (and Unix, probably) has a "file" command, which allows you to check what type a file is, detecting it even if the extension is wrong/missing. If you don't mind spending time on it, also check the metadata - I'll check if there's an easy way to do that.

**Beirut** · 12-07-2009, 20:07

Originally Posted by Sevis

Indeed we have, but I truly am curious how wrong my advice was. To adjust it, Beirut: Make sure that the files you copy contain what you expect them to contain (are valid images, music, etc.) and that their extension really is what you expect it to be. If you're unsure, Linux (and Unix, probably) has a "file" command, which allows you to check what type a file is, detecting it even if the extension is wrong/missing. If you don't mind spending time on it, also check the metadata - I'll check if there's an easy way to do that.

Though I am an unqualified genius, I am also a bear of very little brain. The easy way, for me, is always the best way.

I'll probably have to re-install XP for at least a few months. Don't think I have Win7 cash right now, not with kids and Christmas three-weeks away.

I guess the best I can do is reload, stuff in as much anti-everything as I can, scan everything I want to put back in and use my router(!), which I have not been using of late, and sure as shoot, "of late" is when this machine got bombed.

I'm still curious if it's worth paying for a "better" anti-virus or is the free stuff just as good.

**Tellos Athenaios** · 12-07-2009, 23:59

Originally Posted by Sevis

I'll test this later (giving an executable a .gif extension) - do you perhaps mean the hidden extension "feature" in Explorer? Whoever thought that thing up deserves no compassion.

Try this:
(On a Unix like system, e.g. Linux)

Open GIMP or similar editor. Create a 1x1 px file
Save As GIF (e.g. test.gif)
Include the following comment while exporting:

; echo "Hello, $USER: how do you like your GIF?";

Run as:

Code:

sh test.gif 2>/dev/null

Now imagine doing a similar thing but instead of including POSIX sh compatible code like that; include some DOS code such as

; del *.*;

and naming your file test.gif.bat.

An unwary user can be easily tricked like that: a legitimate GIF picture can double as host for a malicious payload via this double extension trick; which when opened via explorer (double click) would typically result an inexplicable DOS prompt; a bunch of errors in it and much more room on your hard disk. The reason is shells don't abort scripts on error.

The real problem is of course that GIF files and other such containers can be used to inject pretty much arbitrary data. And that by design parsers must *ignore* such data if they do not understand it -- this is essentially the deal with forward-compatibility. And that some OS'es *cough* Windows *cough* have no sensible defaults.

**Sevis** · 12-08-2009, 06:54

I've not got GIMP on me at the moment, so I'll test that later.

As I said - it's the hidden extension. In this case, on Unix, "test" is the name and "gif" the extension, while on Windows, "test.gif" is the name and "bat" the extension. The program is not parsed by whatever image viewer you have - it's sent right into cmd.exe, which will of course be quite dangerous. Would having the first example (in Unix, in a graphical environment), named "test.gif.sh", double-clicked, do anything else? I rather doubt it.

The problem, I would say, is file browsers sometimes hiding extensions, and users not doing anything about it. Checking the (entire) file for possibly dangerous strings and limiting the use of those would take quite a while and have no difference on the typical (used-as-intended) experience.

However, this post has gotten me curious as to how long it would take for 'cat /dev/urandom | grep "; rm -rf /;"' to give us something... Probably too long to wait, the chance per character is 256^-11 (=2^-88, which is around (10^-24)/256).

**Beirut** · 12-08-2009, 11:54

Originally Posted by Sevis

However, this post has gotten me curious as to how long it would take for 'cat /dev/urandom | grep "; rm -rf /;"' to give us something... Probably too long to wait, the chance per character is 256^-11 (=2^-88, which is around (10^-24)/256).

You know, the nerd in me needs a cigarette after reading posts like that.

Ah feel faint...

But you guys know your stuff. I DL-ed Avast and a few minutes later a little screen pops up and says "Dingwad! You have a rootkit messing with your rig." It even warned me I was being attacked. Wild little program.

A scan and a few clicks later and things are much better.

Thanks, y'all.