Gah! Need better anti-bug stuff

[Sevis]

I do not know where you got that idea from. But in short: it is wrong. First of all: many of those are container formats (thus: containing fairly arbitrary data by design). Secondly some of these formats (e.g. GIF) are actually a relatively well-known attack factor: these formats can act as a mask for download scripts for instance.

But even if the other 2 arguments are not a concern: by design a file on an NTFS partition contains an *arbitrary* amount of *arbitrary* data streams. You can access them socket-style: \\path\to\file:streamId. So it is the easiest thing in the world for a piece of malware to simply attach another, arbitrary data stream to given data.

This is the actual reason why it would indeed be a bad thing to copy DLL's or EXE files. Not because those file formats themselves are so insecure (indeed, these formats take more data-integrity precautions than most; embedding checksums for instance) but because these formats contain executable code -- which combined with the NTFS idea of a file means that it becomes possible to inject *executable* code in other files. A decent AV kit should check for such attached data streams though.

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.

I didn't know about the NTFS data streams (and I still see very little point in such a function), 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?

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?

[Beirut]

Sevis,

Sounds like you have the tech-stuff down cold. What's the best anti-everything setup to have, freeware and/or payware, in your opinion?

[Sevis]

Beirut,

That's actually not really my field of specialisation, seeing as I've using things other than Windows for some time now. My general setup whenever I install XP to play games or whatnot is:

• Avast!
• Firefox
  
  • Adblock
  • NoScript
  • CookieSafe
• No flash

I am behind a router, which acts as a firewall, and I've not had any viruses with it for quite a while - however, this is with very sane browsing. Whether such a system could hold up to a stress-test is hard to say.

There is a method that I intend to try out next time I install, which works by "freezing" your files into the state they are, and only allowing the changes you want to actually be saved. For instance, any changes to .exe files can immediately be considered bad - those files just aren't meant to be modified.

[CrossLOPER]

• Avast!
• Firefox
  
  • Adblock
  • NoScript
  • CookieSafe
• No flash

Apart from CookieSafe, this is pretty much my set up. No flash is a bit annoying, but it has its uses. I can't imagine why people still use IE, let alone look at me like I'm a freak when I suggest Firefox.

[Tellos Athenaios]

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]

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]

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]

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)

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

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

Run as:

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]

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]

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.

[pevergreen]

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

Thanks, y'all.

What we love to hear.

Even if they completely lost me towards the end...