kmowery

One of my favorite vim plugins is https://github.com/sjl/gundo.vim , which can open a pane showing the actual tree of versions, including at what time the version changed. j and k can move around in the tree, and the pane with the file will show what it was at a given time. I've definitely used it to pull out a version of a file as it existed an hour ago...

The starting research that enabled this security work appeared last year at ISCA, but didn't fully discuss the security implications:

https://www.ece.cmu.edu/~safari/pubs/kim-isca14.pdf

Yeah, it definitely needs to be kept secret. Since you specified that A and B can have a set-up phase before C is around, the initial setup is fairly straightforward.

Depending on what the system is used for, how valuable breaking into it would be, and how long you expect it to be up, you might need to rotate the key every so often, by having A and B agree on a new key. This is a little more complicated; since B now needs to check C's HMACs against two keys (the original and the new one) until every message signed by the original key has expired.

I'd agree. An HMAC allows A and B to send messages to each other, through C, without C being able to change or modify the message in flight.

A and B just need to share the HMAC key. Handling (and changing) this key can be tricky; if an attacker acquires it, the entire scheme falls over.

That's still fairly straightforward; change the message A signs to "I trust Gamma. Nonce: whatever. Valid Until: DateTime". B should then 1) check the signature and 2) check the datetime (in that order).

This is covered in the Range-R FAQ:

http://www.range-r.com/FAQ/index.htm

The RF bands they're using apparently don't go through metal so well.

Sure! It's ripped + modified from a project I'm working on, so it's a little messy:

http://pastebin.com/ijr3thE2

It does a cmp+setz, which isn't a branch (and I believe is constant-time). An x86 branch would be cmp+jne or something similar.

I've been writing a bunch of branch-free code recently, so I took a crack at it. In my world, data-dependent table lookups might as well be branches, so let's eliminate those as well.

Here's a fizzbuzz(char*, int) function that can accept any number up to 99999999, and will put the correct FizzBuzz result into the provided buffer (either the printed number, "Fizz ", " Buzz", or "FizzBuzz"). As promised, it's loop-free, and as a bonus it should be constant-time as well:

Assembly: http://pastebin.com/EnJEuxnp compiled from this C: http://pastebin.com/PCQQQ2cn [edit] generated from this Python: http://pastebin.com/ijr3thE2

Pastebinned since it's about 700 assembly instructions.

Unrolling the loop and printing to the screen are left as exercises...

I believe they were referencing that in English it is "referrer", but has been misspelled in HTTP forever as "referer".

It's a little less clear than that, unfortunately. Apple chose to not support third-party Bluetooth LE dongles, which might be a reasonable engineering limitation. However, if you upgrade your Mac with a BT-LE capable board used by other Continuity-capable Macs, you still can't use Continuity by default; you need to patch some kexts and disable kernel kext signing[1].

It really does feel like Apple blacklisted older machines from using Continuity; only third-party kext hacking can get things started again.

[1] https://github.com/dokterdok/Continuity-Activation-Tool/

No, they reproduced on "Intel (Sandy Bridge, Ivy Bridge, and Haswell) and AMD (Piledriver) systems using a 2GB DDR3 module." (see Section 4)

They evict cache lines using the CLFLUSH x86 instruction, which I believe is unprivileged.

It's not that the key is generated in Javascript; it's more that the key is generated (and therefore known) by someone who is not you.

Maybe you trust StartSSL with your private key, maybe you don't, but in either case not giving them your private key is preferable.

We don't have one of those machines to test on, so we can't say for sure.

We think it's likely that they went through the same sort of evaluation process that put the Secure 1000 into service, and that they should be publicly reviewed by independent researchers.

Hi! Lead author here.

We'll be giving a talk on this work tomorrow at the USENIX Security, but I'm happy to answer any questions you have here before then.

Yes we did! Any organic material shows up pretty well under backscatter X-ray, and so can be used to cover darker contraband. You can see this done with Teflon in our gallery: https://www.radsec.org/gallery.html under "Concealing a Knife by Masking".

We didn't try meat due to the mess, but it would almost certainly work as well!

(Technically, in this X-ray energy spectrum, the amount of backscatter is related to the "effective Z" of the material, where Z is the atomic number of the elements involved. Materials made from lighter elements like carbon and oxygen? Backscatters well. Heavy elements like iron? Absorbs x-rays.)

That's correct. We think the millimeter wave machines should be looked at in a similar adversarial study, but we don't have access to one for testing.

You'd be surprised how difficult it was to bring it on campus and actually turn it on! Over the course of the project, we worked with our IRB, radiological safety experts, regulatory compliance, and campus public safety before we put someone in front of the device. We set the machine up in a lab with a concrete wall to backstop the radiation, and had a 2 meter safety zone around it while it was actually emitting X-rays.

As for procurement, we purchased our machine on eBay from a private seller who purchased it from a U.S. government surplus auction.

The $1 billion number covers procurement, deployment and usage of both the Rapiscan Secure 1000 backscatter X-ray and L3 ProVision millimeter wave AIT systems.

The Secure 1000s have been removed; the L3 ProVisions are still deployed in airports.

That's correct. We have our own machine and tested it in a lab setting; we never attempted to smuggle contraband in the field.

Hi! Lead author here.

We'll be giving a talk on this work tomorrow at the USENIX Security conference, but I'd be happy to answer questions here before then!

Hi! Lead author here.

We only had a person in front of the X-ray scanner a few times, to minimize exposure. Most of the time we scanned a radiological "phantom", which is designed to look exactly like a human under the X-ray spectrum.

As a complete derail:

Floating point, as IEEE standard? Beautiful. Elegant. One of my favorite technical standards. Other than the +0/-0 thing, it's perfect.

Floating point, as implemented? Ugh. You've got processors which implement some subset of x87, MMX, SSE, SSE2, SSE4, and AVX, all of which handle floating point slightly differently. Different rounding modes, different precisions, different integer conversions. Calling conventions differ between x32 and x64. Using compiler flags alone on Linux x64, you can make 'printf("%g", 1.2);' print 0. Figuring out the intermediate precision of your computations takes a page-sized flowchart: http://randomascii.files.wordpress.com/2012/03/image6.png

It's a mess.

This sort of 0-day has been known in the academic literature for some time[1].

Disclosure of critical vulnerabilities in implantable devices is far more fraught than your normal critical software 0-day. These devices require surgery for replacement, and a small number of those surgeries will have possibly fatal complications. The cost of immediately replacing all existing vulnerable devices could literally be measured in lives. (And that's even assuming that the device manufacturer fixed the problem!)

Implantable software is already a very tricky area, and there's no signs that it'll get any easier.

[1] Pacemakers and Implantable Cardiac Defibrillators: Software Radio Attacks and Zero-Power Defenses, http://www.secure-medicine.org/public/publications/icd-study...

Almost certainly repost prevention... I tried to add this article yesterday and was upvote 4 on the previous link. It just didn't get the random boost it needed to make it to the front page.

git commit --amend is rewriting history, just not very much of it. If you --amend after pushing, you run into the exact same problems mentioned before.