File Transformation

Factual Questions
1

Hope some of you techies can help with this computer security question…

Lets say you have a file, such as a quicken file, that you use on two different computers (i.e. at work and at home, and you back it up on a thumb drive to use between the computers)… Is it possible for one to add some type of code, or other file (i.e. picture, db file, word doc, etc) to the original file? :confused:

My boss is concerned if one was to add some type of mischevious code or file to the original file while I am using it at home, that it could harm the work computer or leak work related material somehow… we use virus checkers, and other security measures, so I am not to conerned about the regualr issues (i.e. virus or spyware)… Thanks for your help!!! :wink:

2

If the original file does not have an executable extension, adding any data to the file will not make it executable (unless the file extension itself was tampered with).

If the original file supports macros, it is technically possible to add a malicious macro to the file. However, malicious macros are usually caught by anti-virus software.

It is possible to lace an executable file with malicious code, but again anti-virus software usually catches any such tampering.

I am not familiar with the quicken file format or the Quicken finance software, so I cannot comment specifically on that. However, it is unlikely (imho) that your quicken data files can be used to create havoc on your work network.

It is still possible that your quicken files could get corrupted by a virus on your home computer (if you do not have a good and updated anti-virus software installed), or that your quicken files on your home computer could get compromised (if your home computer and network security are not strong).

Ultimately, it’s a judgement call between perceived risk and the benefit of being able to work on the files from home.

3

It’s at worst a very small risk. Like Rico said, files for programs that support macros could possibly be contaminated. If you have some virus on your home computer, it’s conceivable but very unlikely that it could use, say, a Word or Excel file as a vector. If Quicken supports macros, and the macro language is sufficiently powerful to pose a danger to a computer, then there is a potential - albeit an absolutely miniscule one - for trouble. Other types of files, aside from executables (i.e. actual programs) are not usually any real risk.

To my knowledge, not many bits of malware nowadays spread by infecting random files and hoping you’ll take them somewhere interesting. Exploits revolving around the internet - i.e. deliberately spreading themselves by finding security holes in the operating systems of other computers connected to the net, or emailing copies of themselves to other people - are the norm for viruses. It seems unlikely a virus writer would even bother with what your boss is describing, since it’s obviously a much slower and less certain means of transmission.

4

I totally called xash “Rico”. Meh. Moderators are essentially interchangeable, I guess.

5

Nitpick: It is possible (though rather tricky) to execute code through a non-executable file, even one that doesn’t support macros. However, this would depend on smashing a buffer somewhere in the program that opened the file. About two years ago there was a case where you could run code on a Windows box through a carefully corrupted JPG file, because of the way Microsoft’s libraries handled them.

6

[QUOTE=MrJackboots]
Nitpick: It is possible (though rather tricky) to execute code through a non-executable file, even one that doesn’t support macros. However, this would depend on smashing a buffer somewhere in the program that opened the file. About two years ago there was a case where you could run code on a Windows box through a carefully corrupted JPG file, because of the way Microsoft’s libraries handled them.
[/QUOTE]

Right, but talking real-world dangers, this one is about as likely as accidentally breaking your mother’s back by stepping on a crack in the sidewalk.

7

Quicken data files are pure data files – they do not have any macro language component that executes. (At least, not up to the latest release, when they made the file formats proprietary. Now we can’t tell what’s in those data files. But realistically, they probably aren’t much different. If they’ve added a macro capability, it’s pretty useless, since they haven’t publicized it.)

[QUOTE=MrJackboots]
Nitpick: It is possible (though rather tricky) to execute code through a non-executable file, even one that doesn’t support macros. However, this would depend on smashing a buffer somewhere in the program that opened the file. About two years ago there was a case where you could run code on a Windows box through a carefully corrupted JPG file, because of the way Microsoft’s libraries handled them.
[/QUOTE]
But there was nothing wrong with the jpg file format, just a bug in the way Microsoft code handled improperly-coded jpg files.

But Microsoft doesn’t do anything with Quicken files (except standard file operations, like copy, rename, etc.). They sell a competing product, Microsoft Money, so they certainly aren’t going to provide any special coding to make working with Quicken files any easier.

Actually, I think MS Money has a conversion feature that will read in Quicken files and convert them to Money format. So I guess there would be a teeny tiny possibility of improper code execution here:
If someone wrote malware to attach executable bad code to Quicken data files,
and you somehow got your Quicken data files infected with that malware,
and you happened to be converting from Quicken to MS Money, using that infected data file,
and MS Money’s conversion function had a similar buffer overflow bug that allowed unauthorized execution of code – then this could happen. But that’s really nitpicky, and just incredibly unlikely to happen.

8

[QUOTE=t-bonham@scc.net]
But there was nothing wrong with the jpg file format, just a bug in the way Microsoft code handled improperly-coded jpg files.
[/quote]
It’s worse than that: Microsoft allowed JPEGs to contain arbitrary executable code which a standard DLL would then execute, apparently at full privilege levels. There’s no way to protect yourself against stupidity that extreme when you don’t have access to source code.

That we know of. And we don’t know much, or else we wouldn’t be talking here. (NDAs and all that.)

Anyone who thinks buffer overflows are rare is living in a world substantially better than the one that includes closed-source software.

9

[QUOTE=Derleth]
It’s worse than that: Microsoft allowed JPEGs to contain arbitrary executable code which a standard DLL would then execute, apparently at full privilege levels. There’s no way to protect yourself against stupidity that extreme when you don’t have access to source code.
[/QUOTE]
Additional detail, and quite true.

Much of the current problems we have with viruses, spyware, etc. are due to Microsoft’s decision to write this kind of tightly integrated, auto-calling operations into their operating system. And why did they do this? To try to make their all their software products work more tightly together. In other words, to try to encourage monopoly control of the software market!

Quite a benefit for them, not much for the customer. So you not only pay more for their monopoly software, it comes with designed-in security weaknesses.
(But now, with Windows Live OneCare, you can pay them more money to solve the security problems they created.)

[QUOTE=Derleth]
Anyone who thinks buffer overflows are rare is living in a world substantially better than the one that includes closed-source software.
[/QUOTE]
I didn’t say (or mean) that buffer overflows are rare.
Just that with all these things that would have to happen simultaneously, the chance of a Quicken data file triggering unauthorized executable code is rare & unlikely.

10

[QUOTE=t-bonham@scc.net]
I didn’t say (or mean) that buffer overflows are rare.
Just that with all these things that would have to happen simultaneously, the chance of a Quicken data file triggering unauthorized executable code is rare & unlikely.
[/QUOTE]
Well, I suppose that’s true. Just don’t embed any JPEGs that claim to be screensavers from the second cousin of the nephew of the deposed Nigerian tyrant who will give you free Applebee’s meals for life if you forward this email to Craig Shergold.

11

It might be more useful, rather than using this thread as a space to rant about the poor quality of Microsoft software, to provide a factual appraisal of the threat. The exploits you guys are describing are well-known (the anti-Microsoft publicity machinery, at least among nerds, is pretty effective.) Has any of this stuff ever been spotted in the wild? Anything involving the JPG buffer overrun? Is Remington64’s company in any real danger if he takes files home to work on? I’m stickin’ with no. These threats are miniscule to nonexistent in the real world. Frankly, if a virus or a bit of spyware spread through an elegant (and ineffective) mechanism like putting wicked code inside a JPG, I’d eat my hat and/or other articles of clothing. There is no realistic risk associated with this.

12

[QUOTE=Remington64]
My boss is concerned if one was to add some type of mischevious code or file to the original file while I am using it at home, that it could harm the work computer or leak work related material somehow… we use virus checkers, and other security measures, so I am not to conerned about the regualr issues (i.e. virus or spyware)… Thanks for your help!!! :wink:
[/QUOTE]
I have dealt with exactly the same fear with my own boss, who was under the unshakable impression that a virus could be attached to any kind of file, even a txt file, or in the specific case he was worried about, a dbase table.

The biggest risk in your situation is that you could compromise sensitive company data by carrying it out of the door, then losing, giving away or selling it to some interested party. Presumably there has to be some kind of trust, but perhaps a password-encrypted thumb drive would be good, to make sure that the data is unreadable if you drop it somewhere.

The second biggest risk (but still not all that great) in your situation is that you would inadvertently or deliberately bring something additional back through the door - another file on the thumb drive, for example, but one that is executable (and if AutoRun is enabled on the machine you plug it into, this malware could execute itself with no action on your part other than just plugging in the drive).

Other risks to consider in your situation include:
-Overwriting the file the wrong way (i.e. you take the file home, work on it, bring it back, then accidentally copy the file from your desktop computer to the thumb drive again, overwriting last night’s work)
-Overwriting someone else’s work, that they carried out on the machine at the office, not knowing that you had taken away the ‘live’ copy of the file to work on it.
-File corruption during all this moving and copying about; if the corruption isn’t noticed until after you’ve copied it back to your office computer, then you could find yourself without any current working copy of the data.
These last few risks are all easily overcome or mitigated by a sensible backup policy and a few simple administrative precautions.

13

[QUOTE=Excalibre]
Has any of this stuff ever been spotted in the wild? Anything involving the JPG buffer overrun?
[/QUOTE]

Yes, actually. I used to collect computer viruses, and I have a captured copy of an in-the-wild JPG exploit around here somewhere. It was spammed to USENET a couple times, about a month after the vulnerability was announced, and continues (in various forms) to resurface now and then, the same way you see a few Blaster and Sasser outbreaks every few months. I saw one infected machine personally, back when I was fixing computers for people around the dorms, but it was a secondary infection; whoever wrote that thing was smart. It’s not obvious if you’ve been infected.

Interestingly, because those libraries are often licensed and used by other companies, which stash their own copies of them in different places on your hard drive, Windows Update doesn’t always make you safe. It’s admittedly an extremely small but not totally negligible risk, kind of like eating fugu (twenty thousand tons consumed per year, fifty to a hundred casualties… it’s slightly riskier than driving to work). Virus writers are damnedly clever people.

Fortunately, I guess, virus writers are also fairly practical people. For at least the past few years, it’s been fashionable to make viruses (worms and trojans, too, but I’ll call them all viruses for now) that make botnets. They’re not interested in your data, because they can make more money, more reliably, by using your computer to blackmail companies with the threat of DDOS, and, as you said, infecting files and hoping they get passed around is pretty inefficient. Once again, it’s a small but not totally negligible risk, perfectly acceptable for most, but not if you’re working on something where security is a neurotic concern, like a bank or a project that needs a security clearance, unless your home computer is also secured appropriately.

Mangetout’s threat assessment is pretty good. You’re probably more a danger to yourself than the virus writers are.

14

[QUOTE=Derleth]
It’s worse than that: Microsoft allowed JPEGs to contain arbitrary executable code which a standard DLL would then execute, apparently at full privilege levels. There’s no way to protect yourself against stupidity that extreme
[/QUOTE]

Are you mixing it up with the Windows Metafile (WMF) exploit? AFAIK the JPEG exploit was just a standard buffer overrun. WMF is an ancient MS file format that allows code to be executed. Since JPEGs are not designed to contain executable code, I don’t think that Windows would deliberately execute any code that might have been hidden in one.

15

[QUOTE=Usram]
Are you mixing it up with the Windows Metafile (WMF) exploit? AFAIK the JPEG exploit was just a standard buffer overrun. WMF is an ancient MS file format that allows code to be executed. Since JPEGs are not designed to contain executable code, I don’t think that Windows would deliberately execute any code that might have been hidden in one.
[/QUOTE]
Here’s some more information on the JPEG buffer overrun that I believe Derleth (and MrJackboots) was referring to:

Buffer Overrun in JPEG Processing (GDI+) Could Allow Code Execution (833987)
http://www.microsoft.com/technet/security/bulletin/MS04-028.mspx

So, technically, yes, non-executable file formats can be vulnerable to buffer overflow exploits due to poor software design. However, in context of the OP’s situation, I maintain that a buffer overflow exploit is the least likely of scenarios.

16

[QUOTE=Usram]
Are you mixing it up with the Windows Metafile (WMF) exploit? AFAIK the JPEG exploit was just a standard buffer overrun.
[/QUOTE]
Yeah, I’m pretty sure there’s not exploit resulting from Microsoft intentionally allowing executable code to be embedded in JPEG files. That’s WMF he’s thinking of.

17

[QUOTE=Excalibre]
It might be more useful, rather than using this thread as a space to rant about the poor quality of Microsoft software
[/QUOTE]
I never ranted about Microsoft software. You might have read something into what I did post.

18

[QUOTE=Derleth]
I never ranted about Microsoft software. You might have read something into what I did post.
[/QUOTE]

I didn’t mean it in a nasty way. And it wasn’t you who said it.