PDF Virus Spotted

Jethro73 writes: "Adobe's popular PDF file format [...] has generally been considered immune to viruses. But a new virus carried by programs embedded in PDF files raises concerns that the format itself could become susceptible. Read about it here and at coderz.net."

Comments

Re:Adobe legal defense

[jmv]

They're gonna yell out "You see what happens when people reverse-engineer our software ?".

Quite the opposite. When writing a PDF virus you're not reverse engineering or circunventing anything. However, if there's a virus in an e-book, you can't study it because then you'd be violating the DMCA and the virus writer can sue you and have you put in jail. Cool isn't it?

Postscript is a complete language

[coyote-san]

Postscript is a complete language, the only reason it doesn't make a good viral platform is that the standard library is extremely limited (some disk I/O, no network I/O iirc) and there's no well-known way to call external libraries.

But make no mistake - it would not be hard to define an extension which allows PS functions to call native libraries. This is the type of extension that could be easily added to support some purpose, without consideration of how this will increase the risk of a viral load.

Finally, to ask the obvious question of why you would do extensive programming in PS, the reason is simple - it allows your file to adjust itself to the printer. E.g., you might have a file which contains meteorological information on a map. If you print the file on a standard printer you get two dozen reports. But if you print it on a large format printer, you get 4x as much information because the file knows it can push additional information onto the map. Or you might get basic information on a monochrome printer, and additional information on a color printer where you can provide visual distinction between the layers.

In some limited cases, you can even have the PS file compute its own content. I've seen that done with some fractal graphics - you might send a <1k file which causes the printer to sit and think for an hour. Great stuff for confusing MCSEs - the print queue says it's printing a 1k file, but it's been churning away for looooon time.

And you can thank...

[dave-fu]

...feature creep. What does anyone need Javascript or anything "dynamic" in a PDF for, anyhow?
When people start applying the KISS principle judiciously, things will get a whole lot safer.

Re:And you can thank...

[SCHecklerX]

It lets you do those inane calculations on the boxes on the US 1040 form and carry data to other fields. It lets you only enter the necessary data and eliminates mistakes based on simple math. Also useful for forms that want things like your name on the top of pages 2-99. Fill in your name on page 1 and it carries through. Want to have an online version of your form and want no legal problems by having two versions of the same form? Put the PDF of the print form on with Javascript validation.

And all of those things could be achieved with an online form, processed and verified on the backend that the administrators have *FULL* control over. Have you ever written a javascript 'application?' Did you know that the '+' symbol is used for both string concatanation and for addition? And usually, javascript will pick the wrong operation : 2+2='22', for example. Yeah, that's how I want my tax information calculated, NOT!

This is almost the same shit I just had to go through with Pennsylvania's braindead online unemployment comensation registration. They did EVERYTHING as a FSCKING javascript/ActiveX client side app. UGH! It is so broken that I ended up just downloading a text form from the web site and faxing that in.

Can someone please explain to me why anybody, ESPECIALLY A GOVERNMENT AGENCY, would write things so heavily dependent on client-side tools?

Below is the letter I wrote to them:

...doesn't work at all under Netscape, Mozilla, Lynx, Links, KFM or Konqueror on linux.

I did not test Netscape or Mozilla under Windows or Macintosh, but the problems could be there as well.

In IE under windows, it caused a GPF 3/4 of the way through, and in several instances did not load properly, not allowing me to fill out fields that were required. Also in IE, your code causes a security alert on *EVERY PAGE* when using Microsoft's default security settings.

WHY are you depending on so much client side code for what amounts to nothing more than a series of forms that are used to feed a back end database? There is NO EXCUSE for a GOVERNMENT AGENCY to be excluding all types of people (including the blind, or the poor who could be accessing your page from a text-only, no javascript browser) from filing for UC Benefits online. It is simply unacceptable.

I am very disappointed in what you have slapped together to file claims online, and hope that you fix it for future unemployed folks who would like to file their claims themselves online, saving everyone time and effort.

Yes, simple javascript can save some time by providing immediate feedback for data verification to the end user...but you depend far too heavily on it. What about people who are using browsers with no javascript enabled at all? They cannot file online. This also breaks a very basic security rule: You can't trust things coming from a client. ALL DATA should be verified on the backend itself.

Since your application is totally useless for me, I decided to use a fax fill out form instead (linked on the same page as the electronic application). Well, it's a week later, and I haven't heard anything, so I called the Lancaster Unemployment Office. The representative there informed me that the preferred method is to file over the telephone, as faxes "can get lost, or sit on someone's desk for a week before being processed." Lovely. Why is the preferred (telephone) method not stated on the web page?

Please re-write the online application. It can be a great tool to file online, but the way it has been done is error-prone and excludes a rather large set of people from using it. These people are then forced to use other methods, causing the entire system to be much less efficient.

Re:Adobe legal defense

[tb3]

Check the second link. The author is 'Zulu' and he says he from Argentina. He gives us the full source code for the damn thing. He also specs out a number of other possible senarios for viruses in PDf files. If Macafee, Symantec, et al were on the ball, they'd be checking sites like this, so they could nip these things in the bud. But then they'd never get their names on CNET and ZDNET every other day.

Me? Cynical?

Re:Not worried

[abischof]

FreePDF purports to convert documents to PDF for free, via a faux-printer-driver (for Win32). I have yet to try it, but its setup does look kinda complicated.

PDF Virus a *Proof of Concept*, not a real threat

[Phoukka]

As many have already noted, the embedded VBScript will only run when triggered by someone double-clicking on the file annotation included in the PDF while using the full version of Acrobat. Thus, the virus is not particularly dangerous.

The social engineering, however, is pretty amazing. The author has created a neat little PDF "game" that people will want to double-click. And, as he wrote in the text file linked above, he wrote it as a proof of concept. The worm doesn't do much except spread itself using Outlook. I think the scary part, the point the author wanted to make, is that you can embed all sorts of fun things in a PDF file. Some other virus writer could make a new version that does something nasty after it emails itself to every address it can find in your Outlook folders.

Yes, the threat level is low, due to the required combination of software and social engineering. But just because the combination of software is rare doesn't mean that we should disregard the possibility.



Now for a display of massive ignorance: I wonder what a PDF virus could do on a system whose GUI is based on PDF (Mac OS X)?