Security Now 395

From The Official TWiT Wiki
Jump to: navigation, search
Security Now
Episode 395

Contents

Security Now 395: Your Questions, Steve's Answers #163

News & Errata

Microsoft Patch Tuesday

Adobe Flash

  • Current version is now v11.6.602.180 for Windows & Mac.
  • Fourth update in as many weeks.
  • No known exploits in the wild, so it's a proactive update from Adobe.
  • Adobe AIR needs update, too.

Java

  • As of March 8, 2013 there are 12 known and unpatched bugs in the Java software released 4 days ago (v7 update 17.)
  • This week's Java Acronym: Just Another Vulnerability Announcement.
  • Another acronym sent by David Blahut: Just Another Valueless Addon

Apache DNT and IE10

  • Review of Apache's continuing discussion about how to handle "Do Not Track" headers in the web server.
    • Discussion in Apache's bug tracker
    • On Github
      • Apache is stealing information from the logic that should actually be looking at this header.
      • IE10 actually asks the user about DNT (in a vague way) so the rationale for the patch is technically invalid.
  • Steve's point: "This is not the job of the server. The server's job is to make the connection and provide the information to the application."
  • The fix is in the config file, but commented out by default.

RC4

  • "Attacks only get better, they never get weaker." -- Bruce Schnierer
  • There are Forthcoming presentation and paper showing full weakness of RC4
    • All weakness/bias in the first 256 bytes have been identified.
    • If you capture repetitive traffic (millions of samples) then you can decrypt the plaintext in the first 256 bytes.
  • Steve explains the fundamentals behind RC4 encryption.
  • There are known problems with RC4's simplicity:
    • Some keys are too weak to initialize the cipher properly.
    • The algorithm could wrap around and reuse keys.
    • There's a certain amount of predictability during the "warm-up" process.
  • WPA fixed the warm-up problems in WEP.
  • 50% of SSL traffic is using RC4 in order to avoid the BEAST attack.
  • Articles discussing the issue in detail:
  • SSLLabs.com has a tool that will evaluate the SSL services of any public server
    • Checks for BEAST vulnerability
    • Cipher strength "grade"

A Little Glitch Hits Bitcoin

  • All Bitcoin versions prior to 0.8 were using Oracle's Berkeley DB.
  • Version 0.8 switched to Google's LevelDB
  • LevelDB is not backwards compatible with the Oracle Berkeley DB because it doesn't have certain limitations that affected behavior.
  • This caused a "fork" in Bitcoins.
  • Discussion at BitcoinTalk Forums
  • Security Now #287 discusses BitCoin

Miscellany

Security Now! Illustrated

CCleaner

  • Steve discovered CCleaner
  • Freeware used to clean up unecessary files from your system

Remote Spying

Play with a FPGA

Spinrite Story

Howard Matthews in Birmingham, United Kingdom

Questions & Answers

Question: [ 01 ] - Nicholas Bauer in Atlanta, Georgia has been thinking about "Loops and Parallels"

Question:
This week when you explained the ability to parallelize chained ciphers, I think you missed the key part that was confusing the questioner:

Which is that usually you aren't trying to compute just one answer, but thousands of them. The idea, which I think was lost on the questioner, is to implement something like an assembly line. As soon as Unit A has computed the output from Input 1 and passed it off to Unit B, Unit 1 can immediately begin work on new Input 2.

Thus, if the hash we are trying to break is 1000 ‘chained” iterations, and let's say we can do 1 iteration per second, normally we'd be computing 1 hash per 1000 seconds.

If we instead implement in hardware 1000 dedicated units, each of which computes one iteration and passes the result to the next unit, we can be processing 1000 units simultaneously, all at different steps in the process. This setup would allow us to compute 1 hash per second, a 1000-fold speedup!

Keep up the great material! It's helped inspire me to do some hobby programming and to be fully conscious of security in doing so.

Answer:
The assembly line comparison is perfect.

Question: [ 02 ] - Sunil Joshi in Chicago, Illinois reminds us about "OneID"

Question:
I remember you talking about OneID sometime ago. I see their site is functional and OneID is being offered.

May be it’s a good idea to do a podcast. Thanks, Sunil

Answer:
It's a proprietary solution. While the solution seems solid and better than OpenID, Steve doesn't think a proprietary solution should win/become the standard.

Question: [ 03 ] - John Chybowski in Poughkeepsie, New York wonders: How Future-Proof are LastPass and similar services?

Question:
Love the show, blah blah blah.

What if LastPass goes out of business? My entire online life is tied up in this excellent service, but I'd still prefer not to have this company's well-being act as a single point of failure, and I'm not sure if LP is completely stand-alone -- you still need to use their servers to maintain your personal blob of encrypted information, correct?

Of course I don't expect this to happen any time soon, but who knows what will happen 10, 20 years down the road.

Answer:
LastPass has done everything they can to solve this problem. Your information is synced through their service but stored locally in an encrypted blob.

Leo also discusses migrating private data to LastPass from Evernote following their recent security issues.

Question: [ 04 ] - Daryl in Kansas reminds of the whacky "mailinator.com" service...

Question:
Steve, I think this is an excellent tool to put in your toolkit! I thought your listeners would like it too. The geek factor is HIGH.  :)

Here's what the website says about it:

  • Use any inbox you like
  • No Sign-up
  • Inboxes are created when email arrives for them
  • Make up email addresses on the fly
  • Make-up address, give it to others, come here and check inbox!
  • RSS/Atom feeds for every Inbox
  • Give out a Mailinator address any time you need an email address but don't want to get spammed!

Thanks for SpinRite and ShieldsUP et al. Hi to Leo!

Answer:
It's such a wacky idea that Steve would never have thought that it could be a service. Received messages have no security and are kept for a limited time. For certain things, it makes a lot of sense: Throw-away confirmation links, etc.

Question: [ 05 ] - "Spencer", writing from an undisclosed location poses two questions about Tor v2.0:

Question:
Hey Steve, you do a great show on TWiT. Two questions about Tor:

1. In your explanation of the old version, TOR, you never explained how the return packets made their way back to the anonymous user. How does that happen??

2. You said these new 'Tor services' are published in the 'Tor directory' so users can find them. Where is this directory, and wouldn't attacking it bring down the whole services system?

Answer:
1. Tor nodes record information necessary to locally return an incoming packet to where it came from, similar to NAT routing.

2. This will be the subject of next week's podcast: The technology of Distributed Hash Tables (DHT). More on this next week.

Notable Quotes

Significant Products

  • ShieldsUp - Test for UPnP vulnerabilities with Steve's recently improved service.
  • JavaTester.org - Java vulnerability tester provided by listener Michael Horowitz
  • SSL Security check - Detect issues with SSL certificate, cipher selection issues, BEAST, etc.
  • CCleaner - File and registration cleanup (Freeware)

Transcript

Sponsors

Rackspace

Carbonite

  • Carbonite.com
  • Use offer code: SecurityNow for 2 extra months if you decide to buy.

Production Information

  • Edited by:
  • Notes:
Info.png This area is for use by TWiT staff only. Please do not add or edit any content within this section.
Personal tools