Extra Pepperoni

Flash sucks even worse than I thought. The Never Ask Again checkbox is not honored in Flash 9.0 r124 (under 10.5.5/Safari 3.1.2), which breaks Flash videos (pretty much Flash's only real reason for being, aside from advertising spyware). I reported this to Adobe, but don't expect much.

Note that I end up with dozens of stacked dialogs, and they pop back up about one per second, so hulu clearly won't work until Adobe fixes this bug, or I give up and turn on Flash cookies (which I have no intention of doing).

******BUG******

Concise problem statement: Flash does not honor setting to not store cookies or local data.

Steps to reproduce bug:

1. Visit http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager03.html
2. Set Global Storage Settings to None.
3. Check Never Ask Again.
4. Uncheck "Allow third-party Flash content to store data on your computer".
5. Restart Safari.
6. Visit http://www.hulu.com/, or http://widgets.nbc.com/cscallback/urlexchange/ (a Sarah Palin SNL clip), or http://www.nytimes.com/interactive/2008/11/04/us/politics/20081104_ELECTION_WORDTRAIN.html

Results: Many many annoying Flash dialogs asking for permission to store data (1 on NYTimes; many on the videos, which interrupt playback).

Expected results: When I check Never Ask Again, I should get NO dialogs asking to store Flash cookies, and no Flash cookies should be stored.

In addition, I unchecked "Store common Flash components to reduce download times." But when I relaunched Safari, it was unchecked. I relaunched a second time, and this setting stayed checked. Never Ask Again was still correctly checked, but I still kept getting obnoxious cookie prompts from hulu.

Update: Leonard Rosenthol informed me that Flash 10 is out. It's a bit hard to find, but does appear to solve the problem. I upgraded, relaunched Safari, reset the option, relaunched Safari, and no longer get those stupid prompts. Hooray! It's odd that Adobe hides it so effectively (it's not even on Adobe's main update page), and the built-in Flash updater doesn't offer it; unfortunately Apple hasn't delivered it to Mac OS X users yet.

Update 2 -- 2008/12/25: Disabling local data (cookies and local caching) prevents Flash videos at Flickr and other sites from playing (I just get a black rectangle of the right size -- no change or controls). YouTube/Google video is not affected, though. I'm not re-enabling Flash cookies, though.

DreamHost wrote back, and the news isn't good. Someone sent them a list which is apparently circulating, of username/password pairs for "FTP" accounts; one was mine. I had hoped that if a password leaked it was my old password, which I replaced back in June (on my birthday) when DreamHost told me they got hacked. No joy, though -- the password they received was active on Extra Pepperoni (and chrispepper.com) until they sent me mail yesterday; I don't use it elsewhere and changed it last night, but that means someone had access to EP very recently. It looks like nobody ever used the account, but methinks it's time to install MySQL and WordPress on www.reppep.com, and probably Mailman too.

Crud on a cracker!

http://www.finjan.com/Pressrelease.aspx?id=1868&PressLan=1819&lan=3

And I still have no idea how they got me.

I've been thinking about using SSL to protect logins to this blog for a while, but thought it would be too complicated. This weekend, I took the time, and thanks to Haris' Admin-SSL plug-in, it was very easy. First I used cert.command to create a certificate for www.extrapepperoni.com, then I configured my DreamHost account to provide SSL (https://secure.reppep.com/ep/) in addition to the existing http scheme; this took a while to go through. Then I installed Admin-SSL, and after a few loading errors, all authentication and authenticated access is now SSL only, while reading anonymously is non-SSL.

Note that I'm using a certificate signed by my private certificate authority, ca.reppep.com, so you'll get a warning from your browser that it's not trusted; this is normal. You can continue past the warning and get full 128-bit SSL encryption; you just don't have the assurance of a public CA that I am who I say I am.

Thanks to Rich & Sam for encouraging me to do this.

Update: After revising more than once, the permanent link to the latest ipfw ruleset is http://securosis.com/publications/ipfw.html.

Over at Securosis, Rich and I posted a piece on using ipfw to increase your security. Leopard's new 'firewall' isn't a network firewall at all. It restricts applications' ability to listen on ports, rather than working at the level of the network stack, which means it cannot do things like allow ssh from home but not from the rest of the Internet. If you want classic packet filtering, it makes sense to use ipfw as well. We cooked up a starter ruleset for people to customize, with instructions on installing it using WaterRoof.

Setting up new Leopard (user) and Leopard Server systems, I was shocked to discover that, in System Preferences:Accounts:Guest, "Allow guests to connect to shared folders" is enabled by default. This is lousy security. Fortunately file sharing is off by default, but I turned file sharing on a day or two before I noticed guest access was enabled. I don't want guest access enabled, and it shouldn't be on without a conscious decision.

I was walking down the street this morning, burning a piece of paper with some old passwords on it, and holding the box of matches I had used to light it. A woman saw me, and said "Hi. Gimme a match?" I got out a match and prepared to light it for her. Before I could strike flame, the woman leaned over to my burning password paper and lit a cigarette from it, then said "Thank you."

There I was, standing on the street, thinking "Smoking's bad, mm-kay," and wondering why she asked for a match when she wanted a light (yes, I know, I cannot turn off being an editor), and thinking this was probably actually not the first time someone's lit a cigarette from a burning password, but it's still unusual.

I got a very interesting (and unexpected) email today. Apparently Apple is in the process of certifying Mac OS X to Federal Information Processing Standard 140, which is used to validate encryption and security technologies -- it's commonly associated with SSL/TLS hardware and software; I know OpenSSL was being validated against FIPS too, but haven't kept track of that progress. I had no idea Apple was working on this, but if and when it's completed, it should be a useful credential for Apple in security-sensitive environments. Note that I make no claims as to the meaning of FIPS certification, but it will be used as a simple checkbox for trustworthiness, so can't hurt Apple to have this particular tick-mark.

From: "Shawn A. Geddis" <geddis@>
To: Fed Talk <fed-talk@lists.apple.com>
Date: Mon, 10 Sep 2007 04:57:51 -0400
Subject: [FIPS 140-2] Mac OS X - Implementation Under Test (IUT)

It's Official -- Mac OS X is now in "Pre-Validation" for FIPS 140-2 Level 1 (Software) Conformance Validation

Everyone has been eager to know the status of FIPS 140-2 Conformance Validation for Apple's Mac OS X and we are happy to finally announce that as of Friday September 7, 2007 the Apple Cryptographic Service Provider (CSP) Module is officially now in "Pre-Validation".

Listed on NIST (CMVP) Pre-Validation List

You will now find the Apple "Cryptographic Service Provider (CSP)" on line 5 of page 2 on the Pre-Validation List (PDF) posted on the NIST CMVP website. To view that list now or reference it in the future, use the following link to download the PDF document:

http://csrc.nist.gov/cryptval/140-1/140PreVal.pdf

What will be covered by this validation

A Cryptography Architecture is built into Mac OS X and is the foundation for services critical to the protection and privacy of data. The key Apple Cryptographic Services which will be covered by this validation are:

FileVault (Encrypted Container - User's Home Directory)

Encrypted Disk Images (Encrypted Container - Stored on any accessible media)

Keychains (Credential Storage)

The FIPS 140-2 Conformance Validation Process

For those who are not familiar with the process and requirements, they can be found on the NIST website at:

http://csrc.nist.gov/cryptval/140-1/preval.htm

1. Implementation Under Test (IUT)
2. Validation Review Pending
3. Validation Review
4. Validation Coordination
5. Validation Finalization

When it will be done

Many have asked when Mac OS X's cryptographic algorithms and cryptography conformance validation against FIPS 140-2 Level 1 will be complete. Apple is unable to provide you with a more specific timeframe than the first half of 2008 due to the extensiveness of the process. Apple will make every effort to post status updates on the Federal website [ http://www.apple.com/itpro/federal/] as well as occasional updates posted to the Fed-Talk Mailing list [ http://lists.apple.com/mailman/listinfo/fed-talk ].

Meeting OMB Recommendations (M-06-16)

To assist Federal Agency IT Staff in understanding how Apple's Mac OS X Operating System can help them meet OMB guidelines, the Apple Enterprise Team had developed and presented the "Meeting OMB Encryption Guidelines with Mac OS X Today" briefing to a large Federal IT Staff on August 17, 2006. Many additional Federal Staff had indicated that they were unable to attend the all day briefing and technical discussion due to scheduling conflicts, but said they were extremely interested in getting access to the presentation.

"Meeting OMB Encryption Guidelines"

http://idisk.mac.com/geddis-Public/security/Meeting_OMB_Encryption_Guidelines.pdf

Background on FileVault

FileVault provides full 128-bit AES encryption of the User's Home Directory where the user has full, direct access to read and write their data. The underlying Encrypted Disk Image architecture also provides services to create, manage and store the encrypted containers on any accessible storage media. This storage includes external volumes such as thumb drives, CDs/DVDs, USB/FireWire HDs and even network accessible volumes.

Background on Apple's Cryptographic Architecture

The Cryptography and PKI Services within Mac OS X and Mac OS X Server are provided through the CDSA - Common Data Security Architecture . The CDSA architecture is the core part of Apple's Security framework which is available from The Open Group and available as open source for review, use and modification.

Open Group - CDSA: http://www.opengroup.org/security/l2-cdsa.htm

Apple source can be found at: http://developer.apple.com/opensource/security/

If you have any additional questions at this time regarding the FIPS 140-2 Level 1 Conformance Validation of Mac OS X , please contact me directly via email at: geddis@

The Register has an interesting article on how to "safely" take your computer to Defcon, with the very wise suggestion that you're safer if your laptop does not go to Defcon. Cellular phones without 802.11 are probably okay for this year at least. They refer back to a much more hard-core SANS post on the same topic.

The exercise is more involved for the fully paranoid, or generally when preparing to enter a truly hostile network. I assume that someone at Black Hat/Defcon has an unannounced exploit that I'd be vulnerable to. This implies you shouldn't have any sensitive data or access to sensitive machines. Since you wouldn't need a laptop without data or access, you probably need to mitigate the consequences of getting hacked.

1. Make up a couple disposable passwords just to use at the conference, one for this machine and one for outside accounts. Destroy them later.
2. Bring an empty USB thumb drive.
3. Create a new email account, so you can send yourself notes/presentations for later.
4. Forward your important email accounts to the new one (keep copies on the normal accounts), so you don't have to check them.
5. Note that if you have a hosting plan like DreamHost's, you can create brand-new ssh and email accounts free. I believe DH offers SSL webmail, if you can ignore the certificate warnings.
6. Get a cheap monthly VPN account, as suggested by Glenn Fleishmann; this is much simpler than establishing a trusted Squid proxy on a non-sensitive box, as originally suggested by SANS; note that you are then trusting the VPN provider.
7. If you have any untrusted protocols, try to access them from your temporary shell account via ssh, or though an ssh tunnel.
8. Back up your data (image the drive -- you will need it later, and a full image is fastest to restore).
9. Wipe your laptop.
10. Install your OS, creating a new account with your new local password.
11. If you have a built-in webcam with an independently software-controlled active light, tape over it. If you feel comfortable opening up your laptop, disconnect its internal microphone.
12. Create a new ssh keypair. If you know the netblock, only allow access from Defcon machines and your own personal host(s); I have some info on doing this in authorized_keys in Take Control of SSH, Draft Excerpt: Public Key Authentication. Make sure your laptop trusts your other (home) machines.
13. Only as needed, trust this new key on your other systems.

14. In your local firewall, block outbound access except to the ports you intend to use; this is easy in Linux, but a bit more complicated on Macs, where you need to write your own startup script (or .command script in Login Items). This is obviously overridable, but an effective way to make sure you don't accidentally connect without encryption, either from habit or because a website redirects you to unencrypted HTTP to save encryption cycles (common). For services where you know what host you'll be connecting to, embed that. Here's a sample of what you might add to add Apple's ipfw. Note that it's easy to shoot your own foot off with outbound firewall restrictions.

    ipfw add 01010 allow tcp from any to 4.2.2.1 dst-port 53 out
    ipfw add 01020 allow udp from any to 4.2.2.1 dst-port 53 out
    ipfw add 01030 allow tcp from any to 4.2.2.2 dst-port 53 out
    ipfw add 01040 allow udp from any to 4.2.2.2 dst-port 53 out
    ipfw add 01110 allow tcp from any to any dst-port 22 out
    ipfw add 01120 allow tcp from any to any dst-port 443 out
    ipfw add 01030 allow tcp from any to smtp.dreamhost.com dst-port 587 out
    ipfw add 01040 allow tcp from any to mail.dreamhost.com dst-port 993 out
    ipfw add 01900 deny tcp from any to any out
    

15. Restore only required information to your laptop.

Enjoy the conference. Hi, Rich!

When you're back home, connect from your home machines to the untrusted laptop, rather than the other way around, retrieve any data on it, and then boot from CD/DVD/PXE and reinstall, or restore from your image if you can do that without using the untrusted OS on the laptop's hard drive.

We were trying to figure out what was wrong with communications between our load balancers and Oracle Application Server this week, and the F5 rep whipped out ssldump. With the SSL key, ssldump can decrypt captured traffic from tcpdump just like wireshark (ethereal) does for unencrypted traffic; apparently it can also do live display of SSL traffic like wireshark, but I haven't tried.

Good stuff!

Adobe just posted a workaround for a security bug in their installer: Security bulletin: Workaround available for security vulnerability caused by installing Adobe Version Cue CS3 Server on some Mac systems.

Thanks to Daring Fireball for the heads-up.

In the Details section of the advisory, Adobe says:

To be granted access to these ports, the installer must first turn off the personal firewall. Currently, it is not automatically re-activating the firewall once it sets up Version Cue CS3 Server, creating a potential security vulnerability.

This is a lie. There is no need to turn off the firewall to add rules. I just discovered that Apple's System Preferences appears to flip the firewall off and on to pick up new rules. This makes things simpler, as Apple can just use existing code to a) edit the configuration file, b) turn the firewall off, and c) turn the firewall on, rather than doing "live insertion" of rules. The truth is, though, that there are two different ways to add rules such as Adobe requires. Both are described in Apple's ipfw manual page.

Adobe's Details tells you what they require:

On Mac OS X, customers can turn on a personal firewall to control how Internet services communicate with their systems. During the installation of Adobe Creative Suite 3, the installer sets TCP ports 3703, 3704, 50900, and 50901, in accordance with Apple’s specification, to allow controlled access to Adobe Version Cue CS3 Server through the Mac OS X firewall service.

One way is to simply add rules individually, such as:

ipfw add 8001 allow tcp from any to any dst-port  3703 in
ipfw add 8002 allow tcp from any to any dst-port  3704 in
ipfw add 8003 allow tcp from any to any dst-port 50900 in
ipfw add 8004 allow tcp from any to any dst-port 50901 in

This is tricky, since Adobe doesn't know what rules their users have, and it's important to insert them into the right place in the sequence.

Another way is to update the rules file and then reload it, as described in the manual page:

 To ease configuration, rules can be put into a file which is processed
 using ipfw as shown in the last synopsis line.  An absolute pathname must
 be used.  The file will be read line by line and applied as arguments to
 the ipfw utility.

In Tiger, Apple's dispensed with the BSD-style rules file, and replaced it with an XML document. I don't know how Apple manages the XML configuration, and perhaps they don't provide a hook to update the live ruleset. Apple's tools should be doing this, but don't. At a guess, someone at Adobe decided to follow Apple's (bad) example and stop & start the firewall, rather than updating the XML configuration file (as they already do), figuring out where the new rules would show up, and then live inserting them (see "ipfw add", above).

Stopping the firewall temporarily is opening customers to unnecessary risk. It's bad, but Adobe's in good company here. On the other hand, saying this is necessary is either a lie about security (never a good idea) or gross technical incompetence (not a real improvement).

If they didn't have the unfortunate bug, whereby the installer neglects to restart the firewall after it's disabled it, we might never have noticed.