Home > Confidentiality, Encryption, Fedora 18, Fedora 19, Fedora 20, Fedora Project, Security > Fedora still vulnerable to the BEAST

Fedora still vulnerable to the BEAST


This morning I was greeted with a blog post from the fine folks over at Qualys on how BEAST isn’t really still a threat (unless you are using an Apple product).  BEAST, a vulnerability found in SSL and TLS 1.0, was discovered around this time a couple of years ago and put web users in a precarious position of using a poor cipher choice (RC4) or be vulnerable.  Not to worry, however, as developers were able to come up with a solution to the problem (n/n-1).

So I mentioned the Qualys article in my $dayjob IRC channel where my always awake coworker provided information that Fedora is, in fact, still vulnerable to the attack.  Thanks to a problem with pidgin-sipe connecting to a Microsoft server, the n/n-1 split was backed out of the NSS software leaving anything that depends on it potentially vulnerable (Chrome, Firefox, and Thunderbird to name a few).

There is a fix, although it’s not fantastic by any stretch of the imagination.  By simply adding these two lines to your /usr/bin/firefox file the vulnerability should be fixed:

NSS_SSL_CBC_RANDOM_IV=1
export NSS_SSL_CBC_RANDOM_IV

We added these two lines at line 36 and restarted Firefox.  My way-too-awake coworker did a test and confirmed that it was working in his environment.  Your mileage may vary.

Hopefully the fix for BEAST can be reapplied to NSS in Fedora soon as leaving users exposed can be dangerous.

Thanks to Hubert Kario for pointing me, and walking me, though this stuff before my morning coffee.

Update: 2013-09-12 @ 14:30 UTC

Apparently this problem will be persistent according to the NSS package maintainer.  From the ticket:

I bit of information from the nss side of things. The nss disabling patch is not applied on Rawhide or f20, onlt applied on stable branches. After we branch Rawhide for the next fedora release and we enter in Alpha, I send emails to the fedora development mailing list telling them that NSS_SSL_CBC_RANDOM_IV=1 will be the default as they use updates-testing and ask for feedback on whether it causes problems. Twice they have said it still causes problems. There are still unpatches servers out there. Once we go beta I have to enable the patch again. f20 is entering Alpha soon so I’ll send that email again. I know this bug is for Firefox but I though worth informing you that we monitor this every six months for nss.

Update: 2013-10-10 @ 15:22 UTC

After several weeks of inaction I’ve filed a ticket with FESCo to hopefully compel NSS to be remedied and any software that breaks with this fix should be patched to undo the fix.

Update: 2013-10-17 @ 10:32 UTC

I believe this problem has been fixed (finally!) for Fedora 19 and beyond.

About these ads
  1. 2013-09-12 at 09:39 EDT | #1

    Is this a firefox bug or a Fedora Bug. Your solution points to the former.

    • 2013-09-12 at 09:54 EDT | #2

      This is a bug in Fedora since they ship the patch that undoes the fix that secures NSS.

  2. birger
    2013-09-13 at 01:22 EDT | #3

    Would it not be better to just set the environment variable in pidgin and possibly evolution? i assume it can’t be set only in the plugins? (pidgin-sipe, evolution-ews, etc)

    Leslie: The real bug here is that maintainers of usually internet-facing services like lync and exchange are not installing their windows security patches. The patch that fixes this vulnerability on windows has been out for a long time. Still people have problems connecting to these windows services as soon as the security fix gets enabled in Fedora.

    I was one of those getting bitten back when this was a new issue, but I should proably set this variable globally on my system to enable the security fix and see if it still breaks anything.

  3. DDD
    2013-09-13 at 04:43 EDT | #4

    IIRC the “per-TLS-packet IV” fix is a feature of TLS1.2, otherwise each packet’s IV is based on the network visible encrypted blob of the previous packet. This can be very bad if you have a malicious server sharing a TLS VPN link, etc.

    There were a couple of “fixes’ (send a zero length packet before each TLS packet to make guessing what the next IV is going to be not quite so trivial), but my understanding is that basically you need to upgrade.

  4. James Wilson Harshaw IV
    2013-09-14 at 23:38 EDT | #5

    As of March 2013, an estimated 65.4% of web sites were supporting protocol variants vulnerable to the BEAST attack, 26.5% vulnerable to the CRIME attack (see below), and 33.8% with insecure ciphers. This is still a big threat, I cannot believe I did not know about this.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 202 other followers