The BFC Computing Weblog: Category Security

Anti-Virus on Voting Machines

Bill McGonigle — Mon, 25 Aug 2008 21:10:00 -0400

There’s been much made of the revelation that Diebold voting machines run an install of McAfee Anti-Virus, and that it’s caused trouble with the voting software.

The arguments against it typically boil down to:

Your voting machines shouldn’t be use for anything else
Your voting machines should be secured against anybody installing software on it
You can’t verify the operation of MAV so it could possibly tamper with votes
You should be running an operating system which is not so easily infected

Those arguments all have merit, but skip the fundamentals - the software image on a voting machine should not be running on read/write media, that is hard drives. If that basic criteria isn’t met, AV software might actually be a good idea, but missing the fundamentals is no excuse for dirty hacks.

I build my first appliance computer that could run from a CD in a CD-ROM drive in 2002. It’s neither new nor a difficult concept. When you need things to be secure, in that case under HIPAA regs, in this case for votes, you mount your media device (hard drive, flash memory, etc) with the ‘noexec’ flag, and then no software installed on the read/write media can be run from that media. Since you can’t write to the CD, software can’t be run from there either. You provide a stripped down OS image to make doing any more than the minimum very difficult, certainly requiring physical access to the machine.

This isn’t to say your machine shouldn’t be kept secure - of course it should, and the BIOS needs to be correctly configured (many of you know the security problems with certain BIOS configurations) - but read-only media and a good Q/A process obviates the need for anti-virus software. Certainly some software selection choices can make this difficult, but any good architecture starts with the requirements and works towards software selection, not the other way around. Assuming good security is a requirement.

Complete Deniability

Bill McGonigle — Thu, 10 Jul 2008 19:51:00 -0400

I’ve written before about the limited usefulness of plausible deniability, especially in relation to software like TrueCrypt, a hard drive encryption program.

The gist of plausible deniability with TrueCrypt is this: You have multiple encrypted hard drive partitions. When your enemy forces you to reveal your keys, you reveal the low-cost key, and the enemy sees some data that he doesn’t care about and sends you on your merry way. The ‘real’ stuff you want to hide is still hidden.

This works if two conditions are true:

The enemy doesn’t know you employ a product with plausible deniability
The enemy can merely detain you

If those conditions aren’t true, you’re in big trouble. Say a violent group gets you and your data. They know TrueCrypt has plausible deniability, and they really want your data. You’re going to be tortured until they get what they want, it’s that simple, and ugly.

Now, the worst possible scenario is that you can’t give up ‘your data’ because it doesn’t exist. But only you know that. The bad guys think you have it and they know you have plausible deniability. You’re completely screwed.

For this reason I’ve been against plausible deniability systems for defending against all threats (yes, TrueCrypt would still be fine from hiding that porn you have stashed away on your home PC).

This changed when Cal Harding introduced the concept of Complete Deniability. That is, you can prove that you have no more plausible deniability.

Here’s how it can work: With TrueCrypt, you could have a utility that, once inside a locked data set, could be given a set of keys and ensure that those keys account for all readable data and all blocks of the storage device. Because TrueCrypt is open source, the bad guys can trust this utility to verify that you’re no longer hiding anything. They can review the source and compile it themselves, if they wish.

But, good news for you, you get to go home. Because even bad guys don’t like to waste their time and you’re not otherwise terribly interesting. Odds are you’re not getting your laptop back once the bad guys find your porn bank, though.

Barracuda Moves Against Trend Micro Bogus Patent

Bill McGonigle — Tue, 24 Jun 2008 18:44:00 -0400

After reading about Barracuda moving to invalidate a bogus patent Trend Micro filed for on virus-scanning at an e-mail gateway (many of my clients depend on this technology) in January, I sent Barracuda the following note:

-----Original Message-----
From: Bill McGonigle [mailto:bill@bfccomputing.com] 
Sent: Tuesday, January 29, 2008 12:24 PM
To: legal@barracuda.com
Subject: possible SMTP prior art - TFS

From:

http://groups.google.com/group/comp.mail.sendmail/
browse_frm/thread/3cee3dc93ea81690/a8cd75d669fbd6b7?lnk=st&q=smtp+virus+scan#a8cd75d669fbd6b7

Its pretty functional - gateways between any/all MS/MAIL,
WP-OFFICE, CC:MAIL, SMTP, UUCP, MCI-MAIL. It does uuencode
and MIME attachments (configurable per address or domain
wildcard) and international characters. It can also virus
scan attachments on the way through the gateway, and access
can be controlled on a user by user basis!

(message dated July 25th, 1995).

It looks like it's still around in some form from foxT:
   http://www.tfstech.com/

Good luck,
-Bill

I never heard back more than a quick “thanks!” from Dean Drako, CEO of Barracuda, but today, I read they’ve moved ahead with this strategy and Goran Fransson, developer on TFS, is a new open source ally.

Dean writes of Goran, “We greatly appreciate the time that Goran Fransson took in coming forward to share this very important piece of prior art,” Drako says. “We believe that his testimony is instrumental in our case against what we believe is an unjust patent claim by Trend Micro against Barracuda Networks and the open source ClamAV project. In our view, Goran is an open source hero.”

Full disclosure: I’ve sold completely open solutions, based on postfix/MailScanner/clamav/sqlgrey against Barracuda’a blackbox appliances, but I’m glad they’re fighting against Trend Micro’s abuse of the system.

Quicktime 7.5 Update Dangerous Precedent

Bill McGonigle — Wed, 11 Jun 2008 20:48:00 -0400

Apple has gone and done something really wrong in terms of security: they released a critical security update wrapped in a feature update.

So, Quicktime 7.5 is required to be protected from the most recently disclosed vulnerabilities. Problem is, as with every other n.X release of Quicktime, it’s buggy. No doubt 7.5.1 and 7.5.2 will be along in a few weeks’ and months’ time, but until then your only choices are to run with miserable choppy playback or to stay vulnerable to disclosed security problems.

This is a really bad idea. There should have been a 7.4.x rev for security as well as a 7.5 with those security fixes.

Flash Vulnerabilty In The Wild

Bill McGonigle — Tue, 27 May 2008 20:18:00 -0400

Ouch.

Every flash-enabled web browser without a Flash-blocking feature (ala NoScript) is vulnerable to remote compromise.

Having this much exposure completely controlled by one proprietary 3rd-party closed-source vendor is bad for the ecosystem. There’s a Free Flash clone underway, but it’s not good enough to replace Flash for many sites that require Flash, and many sites now require Flash.

Please, website designers: Stop hurting the web. Make sites that can be used without Flash, and add all the glam you want around it. Because Flash isn’t an open standard this problem will always exist. AJAX and SVG can accomplish all or most of what Flash can do, and any talented designer can figure these out.

Update: Adobe has updated their info, and it appears the very latest version (9,0,124,0) is not exploitable, thus this is not zero-day, and I didn’t need to publish this article. Title was: “0-Day Flash Vulnerability In The Wild”.

Note on Security Update Coverage

Bill McGonigle — Sat, 17 May 2008 18:14:00 -0400

In the past I’ve covered security problems in various software packages I don’t use or recommend, and I haven’t been doing that for some time, but I don’t think I wrote a note to that effect. Going forward I’ll try not to replicate the work US-CERT is doing and avoid pointing out anything less than problems that are highly out of the ordinary, like the recent debian OpenSSL problem or where official channels are just simply too slow.

Microsoft/Zune/NBC/Watermarking

Bill McGonigle — Thu, 08 May 2008 23:44:00 -0400

People are a tizzy about some ‘magical’ technology NBC got Microsoft to put into its Zune to prevent ‘unauthorized’ episodes from playing. Of course, a he-said, she-said spat ensued, and they’re probably both lying. Anyway, this magic isn’t, it’s just watermarking. It’s well-defined how to make this unnoticeable and non-trival to remove. NBC just adds watermarking to the shows before they air, the Zune detects the watermark, and refuses to play the file unless there’s also an authorization key.

The trick with this approach is that it’s 100% DRM; hardware player support is required, and any other player will not have a problem. Also of note, this does nothing to stop copying, it’s just a revenue-enforcement model and is anti Fair-Use.

Nah, neither GE nor Microsoft would do something like that… good on Apple for refusing to play Evil Ball.

Eliminating Credit Card Fraud

Bill McGonigle — Tue, 18 Mar 2008 22:26:00 -0400

Now that Visa is a Public Company it needs to take responsibility for the harm it creates.

The antiquated system of trading credit card numbers is only something that seems reasonable in a pre-1978 world, one without public key cryptography.

A modern credit card authorization scheme should look something like this:

Merchant requests transaction from Visa for a specified amount of money with a signed/encrypted message
Merchant passes transaction information to client in a signed/encrypted message
Client (human) accepts/declines terms of transaction by passing signed/encrypted message to Visa. Input of a credit card number is optional, and could be replaced by a cert/PIN.
Merchant can check transaction status via signed/encrypted exchange with Visa.
Merchant can handle returns/exchanges via this transaction

This stuff can be easily streamlined today with a simple browser extension or integrated into future web browsers. A physical token (smartcard) is even better, and extends the model beyond Internet transactions.

Just today I learned that my credit card number may have been compromised by shopping at Hannaford’s. There’s no reason for Hannaford to have held onto credit cards for this length of time, that’s just reckless, but there’s also no theoretical reason for them to have to store credit card numbers in the first place.

How many times are we going to have to go through the cycle of:

merchant gets hacked
new cards are issued
everybody changes all of their automated billing setups

before everybody gets fed up? My wife’s card was compromised last summer by shopping at TJ Max, now her card and mine probably at Hannafords. Given enough time, all the merchants are going to get hacked. This will be her second replaced card in a year, and there’s still time for a third. This rate will only accelerate.

More importantly, the current system is a house of cards [ouch - ed.] built on the assumption that every merchant with whom you do business has bullet-proof security. PCI is a pathetic attempt to try to impose IT security upon merchants, but it’s full of holes, and can never be perfect, no matter how hard everybody tries.

The real secret is that PCI is just an attempt to cast blame on the merchants and make it shoulder all of the costs, when Visa is capable of making the whole problem go away and has been for some time.

The disconcerting aspect is that as a non-profit they should have been more willing to do this. Let’s hope real security is an intended use of proceeds from their IPO.

If not, they’ll be displaced by somebody offering much better rates to all the merchants and shopping without fear to the cardholders. Sure, it’ll require large capitalization, but the value proposition is immense. Drop me a line if you want to fund this. ;)

New Myspace Worm?

Bill McGonigle — Fri, 15 Feb 2008 18:43:00 -0500

I got a comment on myspace with the text:

LOL you gotta see the new pics on her profile.

and a link to:

http://profile.myspace.com.index.cfm.fuseaction.user.viewprofile.friendid.518729090.cn/

which is a domain in china, registered thusly.

It looks like the standard MySpace login page. Because MySpace is retarded and throws up login pages all the time at you, most users will assume this is valid. I assume at that point it steals your password and propagates the worm.

Perhaps on some machines it installs malware as well?

I’ll skip the pay-attention-to-your-URL’s preaching, and suggest that writing buggy webapps puts your users at risk by teaching them bad habits.

Turn Off Javascript in Acrobat

Bill McGonigle — Tue, 12 Feb 2008 12:13:00 -0500

There’s another Acrobat security vulnerability today which can lead to system compromise if a user is directed to open a malicious PDF file.

Adobe has an update for Acrobat 8 already, but none yet for Acrobat 7 and they apparently plan none for previous versions. So if you forked out big bucks for Acrobat 6 Professional a couple years ago, they’re not going to support you, even though it’s their bug.

To address this and many future potential problems, go into your Acrobat preferences and disable Javascript. It’s right there in the left list in the preferences window. After all, it’s a document format, not an application platform.

Using alternate PDF viewers, most without JavaScript support, is another option.