guest - flak

observations re packet socket exploit

A few thoughts I had after reading Exploiting the Linux kernel via packet sockets. Not really about the exploit itself, but what it reveals about the state of systems security.

“It should be noted that if a kernel has unprivileged user namespaces enabled, then an unprivileged user is able to create packet sockets.”

Two types of privilege restriction are currently in vogue. There’s the seccomp/pledge model of restricting access to system calls, often referred to as sandboxes. Then there’s the jail/container approach. Hey, sure, give away root access because it’s not really root. Pseudo virtualization. In some sense, these two approaches are similar. Take some code, let it do some stuff, hope it can’t do too much.

Continue reading observations re packet socket exploit...

Posted 2017-05-10 18:41:52 by tedu Updated: 2017-05-10 18:41:52
Tagged: security thoughts

vuln disclosure and risk equilibrium

Some thoughts based on a series of tweets.

“For offence, it doesn’t matter whether the vendor knows a vulnerability exists, it only matters whether the attack works against a target. Fetishising 0day leads to bizarre situations where ppl think that making more vulnerabilities known to more people reduces risk. Fetishising 0day means that people think once a vulnerability is public there’s some sort of automagic immunity.”

So is it possible for disclosing a vulnerability to result in net harm? Maybe, in some circumstances, with some assumptions.

It’s interesting to consider the case of CVE-2016-4657. This is the webkit vulnerability detected when somebody sent a 0day exploit link to an activist. Instead of visiting, he forwarded the link and the malware (Trident/Pegasus) was detected. The bug was of course fixed. But then sometime later, this same vulnerability turned up in the Nintendo Switch. They hadn’t updated their version of webkit, even though the vulnerability was widely known.

Continue reading vuln disclosure and risk equilibrium...

Posted 2017-04-19 14:37:49 by tedu Updated: 2017-04-19 14:39:16
Tagged: security thoughts

colliding, fast and slow

I found it hard to locate a good reference explaining how various hash attacks apply to password hashing. Somebody might reasonably ask how the SHA1 collision, or an extension thereof, would apply to bcrypt. Can bcrypt have collisions? It’s a strange question if you know the answer, but knowing that much requires synthesizing a fair bit of knowledge that’s not all in one place.

Start with the usual crypto hashes. Classics like MD5, current standards like SHA2, new hotness like BLAKE2. All of them are supposed to be collision resistant, and it’s bad news when somebody finds that they’re not. A collision attack is pretty simple to understand. Two inputs have the same hash.

An example attack is Mallory generates two messages with identical hashes, “IOU $10” and “IOU $1000”, and borrows $1000 from Alice, who accepts SHA1(“IOU $1000”) = 0x65de12 as a contract. (Digital signatures usually involve signing a hash of the document.) Later, Mallory pays Alice $10 and produces SHA1(“IOU $10”) = 0x65de12 to prove the debt has been paid. Alice is out $990. This is a collision attack. The adversary has control over both messages and the hash.

Continue reading colliding, fast and slow...

Posted 2017-02-28 22:38:41 by tedu Updated: 2017-03-05 19:12:50
Tagged: security software thoughts

features are faults redux

Last week I gave a talk for the security class at Notre Dame based on features are faults but with some various commentary added. It was an exciting trip, with the opportunity to meet and talk with the computer vision group as well. Some other highlights include the Indiana skillet I had for breakfast, which came with pickles and was amazing, and explaining the many wonders of cvs to the Linux users group over lunch. After that came the talk, which went a little something like this.


I’m a developer with the OpenBSD project. If you’ve never heard of OpenBSD, it’s a free unix like system. So kind of like Linux, but better in every way. Totally unbiased opinion.

Continue reading features are faults redux...

Posted 2017-02-21 22:02:11 by tedu Updated: 2017-02-21 22:18:32
Tagged: security software thoughts

using yubikeys everywhere

Everybody is getting real excited about yubikeys recently, so I figured I should get excited, too. I have so far resisted two factor authorizing everything, but this seemed like another fun experiment. There’s a lot written about yubikeys and how you should use one, but nothing I’ve read answered a few of the specific questions I had.

It’s not a secret I’ve had a dim view of two factor auth, although many of my gripes are about implementation details. I think a lot of that remains true. Where two factor auth perhaps might succeed is in limiting the damage of phishing attacks. I like to think of myself as a little too savvy for most phishing attacks. That’s sadly true of most phishing victims as well, but really: I don’t use webmail. I don’t have any colleagues sharing documents with me. I read my mail in a terminal, thus on the rare occasion that I copy and paste a link, I see exactly the URL I’m going to, not the false text between the <a> tags. Nevertheless, if everybody else recommends secure tokens, I should at least consider getting on board with that recommendation. But not before actually trying these things out.

Continue reading using yubikeys everywhere...

Posted 2017-02-20 07:14:52 by tedu Updated: 2017-02-21 17:07:50
Tagged: computers gadget security software

RC40 card cipher

The Solitaire cipher is perhaps the best known encryption algorithm implemented with a deck of cards. Ignoring security, it has a few drawbacks. It’s pretty complicated. I can never quite remember the rules. Sure, with practice it’s possible to memorize, but ideally we want something easy to teach. It’s also pretty slow. Even with practice, the shuffling and cutting manipulations take time.

Critically, in this modern age of bitcoins and twitter handles, the supported character set is also a bit limited. Letters only. If we need to transmit a message like “The password is Hunter2.” that could be trouble. Oh, and no spaces.

Continue reading RC40 card cipher...

Posted 2017-02-10 14:27:51 by tedu Updated: 2017-02-10 14:27:51
Tagged: gadget security

exfiltration via receive timing

Another similar way to create a backchannel but without transmitting anything is to introduce delays in the receiver and measure throughput as observed by the sender. All we need is a protocol with transmission control. Hmmm.

Actually, it’s easier (and more reliable) to code this up using a plain pipe, but the same principle applies to networked transmissions.

First the reader code. We’ll assume an input string of decimal digits, 1-9.

Continue reading exfiltration via receive timing...

Posted 2016-12-22 15:20:19 by tedu Updated: 2016-12-22 15:20:39
Tagged: c network programming security

exfiltration via request timing

There are any number of ways to exfiltrate data via covert channels. For example, a popular technique is to make DNS lookups for a series of hostnames like “”, “”, etc. which will be passed through most firewalls. For a long time DNS requests weren’t monitored, but savvy network operators have grown wise. So if we wanted to beam some data off a device surreptitiously, what else can we do?

There are some even lower level techniques, like varying IP packet size or options, but this too may trigger alarms. Instead, let’s move up the stack and try to make our tunnel look as normal as possible. Consider the scenario where we’re Apple or Google and we want to extract Signal private keys off a device. It’s a small amount of data, and we already have an established channel: update checks. The trick is to piggyback our channel onto update requests. (This is not an entirely original idea, I just wanted to explore it.)

Continue reading exfiltration via request timing...

Posted 2016-12-19 17:30:45 by tedu Updated: 2016-12-19 17:30:45
Tagged: c network programming security

all that’s not golden

Several stories and events recently that in some way relate to backdoors and golden keys and security. Or do they? In a couple cases, I think some of the facts were slightly colored to make for a more exciting narrative. Having decided that golden keys are shitty, that doesn’t imply that all that’s shit is golden. A few different perspectives here, because I think some of the initial hoopla obscured some lessons that even people who don’t like backdoors can learn from.

Secure Boot

Microsoft added a feature to Secure Boot, accidentally creating a bypass for older versions. A sweet demo scene release (plain text) compares this incident to the FBI’s requested golden keys. Fortunately, our good friends over at the Register dug into this claim and explained some of the nuance in their article, Bungling Microsoft singlehandedly proves that golden backdoor keys are a terrible idea. Ha, ha, I kid.

Continue reading all that’s not golden...

Posted 2016-08-18 18:52:56 by tedu Updated: 2016-09-08 19:47:47
Tagged: security thoughts

random failures

Lots of examples of random numbers failing, leading to cryptographic failure.

The always classic Debian, OpenSSL, and the year of the zero.

The time Sony signed Playstation code with the same nonce and leaked the keys.

Samy phpwned session IDS.

The Bitcoin app Blockchain used for entropy. Bonus giggles for not following the HTTP redirect, but actually using “301 Moved Permanently” as a random number.

The paper Mining Your Ps and Qs has pretty extensive investigation into weak keys on network devices, many of which result from poor entropy.

Continue reading random failures...

Posted 2016-08-05 18:15:21 by tedu Updated: 2016-08-19 04:19:31
Tagged: gadget security software

timeline of libexpat random vulnerability

libexpat calls rand to obtain a secret hash salt. That’s not good. Actually, as far as vulnerabilities go, it’s pretty chickenshit, but perhaps there’s a lesson to be learned.

2012-03-24 - libexpat 2.1.0 released with a fix for an algorithmic hash table attack (CVE-2012-0876). It uses rand() seeded by srand(time(NULL)) to obtain a hash table salt.

2012-04-01 - libexpat 2.1.0 imported to OpenBSD. The rand calls are replaced with arc4random as spotted by deraadt and nicm. April Fools!

2012-04-05 - A public report that using random may be too predictable.

2013 - Tick tock.

2014 - Tick tock.

2015-02-07 - Redhat bug filed. The complaint is not that rand is a poor choice for secret salts, but that calling srand interferes with the proper malfunctioning of other rand consumers.

2016-06-04 - libexpat is the proud recipient of two more CVE awards. By sheer miraculous luck, OpenBSD is not susceptible. Users of other operating systems need not be alarmed as libexpat has been patched to use getpid as a source of entropy as well.

const unsigned long entropy = gather_time_entropy() ^ getpid() ^ (unsigned long)parser;

Lesson to be learned? Sometimes bad things happen and there’s nothing we can do to prevent them. So it goes.

Posted 2016-06-10 05:40:40 by tedu Updated: 2016-06-10 05:40:40
Tagged: openbsd security software

regarding embargoes

Personal thoughts. To each their own.

Yesterday I jumped the gun committing some patches to LibreSSL. We receive advance copies of the advisory and patches so that when the new OpenSSL ships, we’re ready to ship as well. Between the time we receive advance notice and the public release, we’re supposed to keep this information confidential. This is the embargo. During the embargo time we get patches lined up and a source tree for each cvs branch in a precommit state. Then we wait with our fingers on the trigger.

What happened yesterday was I woke up to a couple OpenBSD developers talking about the EBCDIC CVE. Oh, it’s public already? Check the OpenSSL git repo and sure enough, there are a bunch of commits for embargoed issues. Pull the trigger! Pull the trigger! Launch the missiles! Alas, we didn’t look closely enough at the exact issues fixed and had missed the fact that only low severity issues had been made public. The high severity issues were still secret. We were too hasty.

Continue reading regarding embargoes...

Posted 2016-05-04 14:04:17 by tedu Updated: 2016-05-04 21:17:51
Tagged: security software thoughts

more input validation unnecessary

There’s a widespread belief that validating user input prevents security vulnerabilities. This is true as far as it goes, but doesn’t tell the whole story. Consider the following example, distilled from any number of real world examples.

if (!valid_input(buffer)) { free(buffer); error = BADSTUFF; goto ungood; } error = process_input(buffer); ungood: free(buffer); return error;

A not uncommon mistake. A vulnerability report may, quite accurately, say something like “Invalid inputs may result in remote code execution.” However, further input validation won’t fix this bug, nor will tweeting “This is why you always validate your inputs!” prevent future occurrences.

Lots of problems may share similar or even identical descriptions without sharing fixes. It’s a small point, really, but no less important. And of course, hardly limited to the field of security.

Posted 2016-04-25 18:14:33 by tedu Updated: 2016-04-25 18:14:33
Tagged: c programming security

when preloads go sideways

How hard is it to preload a PC with the software it needs to work? Really fucking hard.


Some time ago, Lenovo shipped some computers with a surprise gift: SuperFish. I like to imagine the business development units from each company in a meeting:

Superfish: It will add value!

Lenovo: How does that work exactly?

You give us customer eyeballs. In return, we give you money. Money is value.

But how does that add value for the customer?

Well, it’s their eyeballs we’re buying. Do the math!



Afterwards, we’d naturally expect various other vendors to take a look at the giftware they were bundling. Hahaha. Instead of actually changing anything about their product, Dell just updated their website:

Continue reading when preloads go sideways...

Posted 2016-01-22 21:09:22 by tedu Updated: 2016-01-22 21:09:22
Tagged: bugs rants security software

outrageous roaming fees

Unexpected roaming fees are the worst. You’re just cruising along, having a jolly old time, and then boom. $20 per megabyte??? Should have read the fine print. Of course, if you had known to read the fine print, you probably would have already known about the roaming fees, and therefore not needed to read the fine print. And so it goes, in life and in ssh.

What, ssh has roaming??? Should have read the fine print. The Qualys Security Advisory is more than thorough. Now that we’ve read the fine print, what can we do differently?

The main bug (ignoring the second overflow for now) is that some sensitive memory was recycled and leaked. The possibility of this happening has been known for some time, and there’s some countermeasures in place, but they’re not foolproof.

Continue reading outrageous roaming fees...

Posted 2016-01-15 14:55:50 by tedu Updated: 2016-01-19 04:17:28
Tagged: c openbsd programming security thoughts

reproducible builds are a waste of time

Sort of. Maybe. It depends.

Yesterday I read an article on Motherboard about Debian’s plan to shut down 83% of the CIA with reproducible builds. Ostensibly this defends against an attack where the compiler is modified to insert backdoors in the packages it builds. Of course, the defense only works if only some of the compilers are backdoored. The article then goes off on a bit of a tangent about self propagating compiler backdoors, which may be theoretically possible, but also terribly, unworkably fragile.

I think the idea is that if I’m worried about the CIA tampering with Debian, I can rebuild everything myself from source. Because there’s no way the CIA would be able to insert a trojan in the source package. Then I check if what I’ve built matches what they built. If I were willing to do all that, I’m not sure why I need to check that the output is the same. I would always build from scratch, and ignore upstream entirely. I can do this today. I don’t actually need the builds to match to feel confident that my build is clean. Perhaps the idea is that a team of incorruptible volunteers will be building and checking for me, much like millions of eyeballs are carefully reviewing the source to all the software I run.

Continue reading reproducible builds are a waste of time...

Posted 2015-09-08 17:55:54 by tedu Updated: 2015-09-19 20:19:36
Tagged: rants security software thoughts

on the detection of quantum insert

The NSA has a secret project that can redirect web browsers to sites containing more sophisticated exploits called QUANTUM INSERT. (Do I still need to say allegedly?) It works by injecting packets into the TCP stream, though overwriting the stream may be a more accurate description. Refer to Deep dive into QUANTUM INSERT for more details. At the end of that post, there’s links to some code that can help one detect QI attacks in the wild. As noted by Wired and Bruce Schneier, among dozens of others, now we can defend ourselves against this attack (well, at least detect it).

Continue reading on the detection of quantum insert...

Posted 2015-08-06 02:24:12 by tedu Updated: 2015-08-06 02:24:12
Tagged: project security software web

rolling expired certs

This wasn’t the post I intended to write today, but then I noticed that the certificate for had expired, and repairing that became a prerequisite for getting anything else done. At the time, my first snarky thought upon discovering Firefox wouldn’t let me connect to my site anymore was “Oh, hurray, don’t I feel safe.” Then I went through the update nonsense and thought a bit more seriously about it.

My cert expired after a year because that seems to be the thing to do. I imagine there’s some nebulous threat model where somebody stole my server key and has been impersonating me for the past six months, but now they can’t. Although, if they stole the old key, they can probably steal the new key. I suppose we do this because revocation doesn’t work, but a six month half life is a long time to sit exposed.

Continue reading rolling expired certs...

Posted 2015-07-08 18:46:29 by tedu Updated: 2015-07-08 18:46:29
Tagged: rants security web

signify shortcomings

I presented a talk about signify at BSDCan on Friday. It went really well; during and after the talk many people told me I was wrong.

Here’s a list of things that are less than perfect, either with the signify tool or with its usage.


Some issues affect the signify tool itself. I’m happy that so far they’re quite minor.

Secret key files contain a 64-bit hash (truncated SHA512) of the secret key data which is used to verify the user’s password. You wouldn’t want to enter the wrong password and accidentally sign something with a bogus key. Unfortunately, this creates something of an oracle. If you steal somebody’s secret key, instead of guessing passwords which will be terribly slow because of the KDF, you can just guess keys and compute hashes until you get a match. The good news is that the key space is fairly large; you won’t have much luck guessing one. Harmless as this may be, it’s bothered me quite a bit because it’s plainly wrong. (The rationale for this decision was that encrypting the hash as well would require another iteration of the KDF.)

Continue reading signify shortcomings...

Posted 2015-06-15 12:54:10 by tedu Updated: 2016-09-27 22:11:59
Tagged: openbsd security software

as always bundling fixes is bad

I generally like my iPhone. I think it’s fairly secure, and Apple seems pretty motivated to keep it that way (even if they don’t have the purest intentions, caring perhaps more about jailbreaking than my safety). But the way the way they go about releasing security fixes is terrible.

Highlighting two lines from a preview of iOS 8.3. First:

“As always, it’s a good idea to wait a few days to see if the update causes any problems.”

Sound advice. My phone is pretty important. I don’t like when it doesn’t work.

“As always, the iOS update includes a slew of security fixes.”

Cupertino, we have a problem.

I figure 24 hours is about the amount of time it takes from a security patch to be released until weaponized exploits show up. After that, if you’re not patched, you’re living dangerously, depending on the nature of the bug. Bundling new features with a high risk of regression with security fixes means users wait to upgrade.

The iOS 8.3 update is 280MB. It can’t even be downloaded over the air, only via wifi. Security patches are important enough that they should always be made available separately. Then I could download them, even OTA, without fear of regression.

What aggravates me most is that this is business as usual. As always. We’re training people not to patch. Users should be embarrassed to admit they’re running unpatched software; instead it’s regarded as the prudent choice.

Posted 2015-04-09 16:02:55 by tedu Updated: 2015-04-09 16:02:55
Tagged: gadget security