First, the high-level conclusions:

• Except perhaps in deeply-embedded environments, all of C89’s library is universally available.
• Code not intended to run on Windows can also assume most of C99 and much of POSIX. The less-ubiquitous headers from these categories are also the less-useful headers.
• Code that is intended to run on Windows should only use C89 headers and <stdint.h>. If MSVC 2008 support is required, not even <stdint.h> can be used. (Windows compilers do provide a small handful of POSIX headers, but they do not contain the expected set of declarations!)
• Many different Unix variants ship a similar set of nonstandard headers. We don’t yet know whether the contents of these headers are reliable cross-platform.
• There is a large set of obsolete headers that are still widespread but should not be used in new code. This is underdocumented.

The full results may be seen here: http://hacks.owlfolio.org/header-survey/
The raw data is here: https://github.com/zackw/header-survey/

If you want to help, we need more inventories (especially for OSes further from the beaten path), and I’m also very interested in improvements to the giant generated HTML table. Y’all on Planet Mozilla can probably tell I’m not a Web designer. If you are an old beard, there are also places where I’m not entirely sure of my methodology – see the README in the source repo.

Art by Dave Mottram. Found on G+.

One guess per person. Must provide a working email address (or I won’t be able to contact you if you win). Do not suggest a joke now; the winner will be notified of the topic of the upcoming paper, so they can think of something appropriate. Management reserves the right to reject joke suggestions, in which case the next person in line will get a crack at it.

Attention conservation notice: Angry rant about sexism and sexism-motivated abuse in the computer industry.

I was going to write a crunchy, cerebral, if perhaps controversial, post today about how I don’t think Bitcoin is going to change the world, but then I got up and read my usual newsfeeds and discovered that, once again, the Internet’s collection of “gibbering follow monkeys” have decided to hurl abuse up to and including death threats at someone. Someone whom, I am not surprised to find, is female and not white. So now you don’t get crunchy, or cerebral. You get an angry rant, because I have had enough of this shit.

For context, the sequence of events appears to have gone something like this. More details available at GF Wiki.

• Some dudes were making sophomoric, not actually funny sex jokes at PyCon.
• Adria Richards complained to the PyCon organizers and also kvetched about the dudes on Twitter.
• The PyCon organizers told the dudes to knock it off and/or leave the room, which they did.
• The gibbering follow monkeys flipped the fuck out, like they do, and started throwing abuse, DDOS and death threats around.
• One of the dudes was fired subsequent to a “thorough investigation” by his employer.
• Ms. Richards has also been fired, apparently after the abuse widened to include her employer as an organization.

Okay, here comes the rant.

What. The. Fuck. Is. Wrong. With. You. Monkeys?!

Why is it that this type of incident always seems to provoke a nuclear-grade shitstorm?

Why is it so important to you to be able to make sophomoric, unfunny jokes no matter where you may find yourself?

Where on God’s green earth did you get the idea that death threats are an appropriate response to ANYTHING?!

Why are you not ashamed of yourselves?

So tell us how you really feel, Weinberg.

I rather think I just did, but now I’m done shouting, perhaps I will elaborate a bit.

The “sophomoric, not actually funny sex jokes” may seem like a minor thing and not worth complaining about, but there is a fucking track record here. Much more serious things can and have happened to women at professional conventions (both in the software industry and out). By calling out minor bad behavior and publicly telling the perpetrators to knock it off, communities signal that more serious misbehavior will not be tolerated, and then hopefully it doesn’t happen at all. (Note: I am aware that this has been partially discredited as regards violent crime, but if you think it doesn’t work at all, provide evidence to back up your claims, and be aware that you are arguing with Philip Zimbardo.) The initial “hey, this is not cool” report and the “knock it off” response by PyCon seem precisely on the nose to me. Should anyone have gotten fired? Not just because of this incident, certainly, but the “thorough investigation” by the dude’s employer may have turned up something more serious; they, quite properly, do not elaborate. (Commenting in public about why you fired someone is a nonstop ticket to lawsuit land in the USA.) As of this writing, Ms. Richards’ employer appears to be in panic mode and not behaving rationally; I would not be surprised if they calm down tomorrow and pretend it never happened.

Now, as to the shitstorm. There is also a track record here, and for that I’m going to refer you to John Scalzi: “The Sort of Crap I Don’t Get.” He explains how he gets hate mail because of things he does, but he does not get a continuous stream of abuse, nor is it because of who and what he is (unless you count “opinionated and widely read”). Anyone who isn’t a straight white male, however, can expect that continuous stream of abuse, especially if they have a prominent online persona. This is not okay, and this is what I am especially angry about this afternoon. I have seen it happen over and over again to friends and acquaintances and strangers whose writing I read, and what the hell can I do about it?

I can say “WHAT THE FUCK IS WRONG WITH YOU MONKEYS” out loud instead of just thinking it, maybe. Maybe if enough people do that, the monkeys will start to feel some shred of shame.

I can hope.

Thanks for listening. Have a flower.

assert.h
ctype.h
errno.h
float.h
iso646.h
limits.h
locale.h
math.h
setjmp.h
signal.h
stdarg.h
stddef.h
stdio.h
stdlib.h
string.h
time.h
wchar.h
wctype.h

Beyond C89, interesting portability targets divide into three classes. Complete Unix environments are always compliant with C99 and POSIX.1-2001 nowadays, but not necessarily with all of the optional modules of the latter, nor with any more recent standard. Windows has several different competing C runtimes, some of which offer more C99 support than others, and none of which are at all conformant with POSIX. Finally, the major embedded environments are presently all cut-down versions of a specific identifiable complete Unix or of Windows. Those that are derived from Unix usually have most of the POSIX headers but may be missing a few.

EDIT: Everything after this point in the original version of this post was insufficiently thoroughly researched and may be wrong. Corrected tables will appear Real Soon. If you are interested in helping me with that, please see https://github.com/zackw/header-analysis.

□ software □ hardware □ cognitive □ two-factor □ other _________

universal replacement for passwords. Your idea will not work. Here is why it won’t work:

□ It’s too easy to trick users into revealing their credentials
□ It’s too hard to change a credential if it’s stolen
□ It initiates an arms race which will inevitably be won by the attackers
□ Users will not put up with it
□ Server administrators will not put up with it
□ Web browser developers will not put up with it
□ National governments will not put up with it
□ Apple would have to sacrifice their extremely profitable hardware monopoly
□ It cannot coexist with passwords even during a transition period
□ It requires immediate total cooperation from everybody at once

Specifically, your plan fails to account for these human factors:

□ More than one person might use the same computer
□ One person might use more than one computer
□ One person might use more than one type of Web browser
□ People use software that isn’t a Web browser at all
□ People want to present different facets of their identity in different contexts
□ Not everyone can see the difference between red and green
□ Not everyone can make fine motor movements with that level of precision
□ Not everyone has thumbs
□ No one wants to remember a string of meaningless symbols that long
□ Users rapidly learn to ignore security alerts of this type

and technical obstacles:

□ Clock skew
□ Unreliable servers
□ Network latency
□ Wireless eavesdropping and jamming
□ Zooko’s Triangle
□ Computers do not necessarily have any USB ports
□ SMTP messages are often recoded or discarded in transit
□ SMS messages are trivially forgeable by anyone with a PBX

and the following philosophical objections may also apply:

□ This protocol was shown to be insecure by ________________, ____ years ago
□ This protocol must be implemented perfectly or it is insecure
□ This protocol relies on a psychologically unnatural notion of “trustworthiness”
□ This secret is even easier to guess by brute force than the typical password
□ This secret is even less memorable than the typical password
□ It’s too hard to type something that complicated on a phone keyboard
□ Not everyone trusts your government
□ Not everyone trusts their own government
□ Who’s going to run this brand new global, always-online directory authority?
□ I should be able to authenticate a local communication without Internet access
□ I should be able to communicate without having met someone in person first
□ Anonymity is vital to robust public debate

To sum up,

□ It’s a decent idea, but I don’t think it will work. Keep trying!
□ This is a terrible idea and you should feel terrible.
□ You are the Russian Mafia and I claim my five pounds.

hat tip to the original

When it comes to ACM and IEEE elections, I am a single-issue voter, and the issue is open access to research. I will vote for you if and only if you make a public statement committing to aggressive pursuit of the following goals within your organization, in decreasing order of priority:

1. As immediately as practical, begin providing to the general public zero-cost, no-registration, no-strings-attached online access to new publications in your organization’s venues.

2. Commit to a timetable (which should also be as quickly as practical, but could be somewhat slower than for the above) for opening up your organization’s older publications to zero-cost, no-registration, no-strings-attached online access.

3. Abandon the practice of requiring authors to assign copyright to your organization; instead, require only a license substantively similar to that requested by USENIX (exclusive publication rights for no longer than 12 months with exception for posting an electronic copy on your own website, nonexclusive right to continue disseminating afterward).

4. On a definite timetable, revert copyright to all authors who published under the old copyright policy, retaining only the rights requested under the new policy.

Thank you for your consideration.

This is a personal disappointment for me, since I liked the game, but it’s also not the first time I’ve seen an Internet community built around a compelling idea fall apart because the money wasn’t there. Something very similar happened to Metaplace and Faunasphere. It’s not just games; the WELL, paragon of elder days, had to be bought out by its users, and this was only possible because it goes back to elder days and has users who are very, very rich. TV Tropes, timesink par extraordinare and valuable resource for high school English students, is ad-supported so it keeps getting jerked around by Google.

You get the idea: the ecology around the Web is only capable of supporting ideas that bring in the money. It doesn’t really matter how good the idea is on its own terms, or how desirable it is to its audience if that audience isn’t big enough to provide enough money. Kickstarter and the like help with that last bit, but they don’t work for things that need lots of money or a continuous stream of money. Glitch staff quoted a figure of six million U.S. dollars a year to keep the game running, which is comparatively small for a business—thirty-ish people at $100,000/yr, plus however much the servers and the connectivity cost, plus overhead. But one million dollars is extraordinary for a Kickstarter project.

The requirement for a continuous stream of money to keep the servers running also hurts things on the Net that were successful but are now declining. I can still play Super Mario World any time I want; even after the original hardware stops working altogether, there will be emulators. But I can’t go back to Star Wars Galaxies, and I’m not sure if I should believe the website that’s telling me I can still play Uru Live. Again this isn’t just about games; we all remember what happened to Geocities.

Free software helps, but not enough, because it’s not enough to be in possession of all the code and data that you need for a client-server MMO. Some specific person or group has to actually run the server, and now we’re back to that continuous stream of money requirement—most of which will be going to people, not to computrons or tubes. You might not need developers, but you definitely need sysadmins. I was a sysadmin in college, for a tiny little computer lab that almost never had crises at four in the morning, and it was still a shitload of work. For an MMO you also need in-game and out-of-game moderators, which is even more difficult and thankless a gig than sysadminning, and while people do sometimes volunteer to do it for free, often those are exactly the people who should not be doing that job (yeah, I’m looking at you, Reddit).

Is there a solution? I don’t have one. I think it’s more a problem of capitalism than a problem of software architecture.

Note, paper links may go to expanded technical reports instead of as-presented papers, since obviously I am not going to link to the “official” editions behind ACM’s paywall. There were some talks that I didn’t write up, despite their interestingness, because I couldn’t find an unencumbered paper to link to—cavete auctores!

Monday (WPES)

An Approach for Identifying JavaScript-loaded Advertisements through Static Analysis

Right now the state of the art for blocking out ads on the Web is with gigantic URL-based blacklists—the popular “EasyList” for AdBlock Plus contains 18,000 entries according to the speaker, with new entries added at a rate of five to fifteen a week, and obsolete entries hardly ever removed. This paper proposes instead to use static analysis and machine learning to detect ad-related JavaScript and prevent it from executing. The claim is that this will be easier to maintain, more robust, and scale better. They wrote a browser extension that preprocesses incoming JavaScript through some “basic optimizations” (constant folding, mostly) and then looks for a handful of features that are more likely to appear in ad-loading JavaScript. There are a number of problems related to figuring out what to do next (see the paper) but as a proof of concept it seems to work quite well, with classification accuracy in the 98% range. It has trouble with analytics and HTML generation libraries, both of which share features with ad-loading scripts.

In the question period, someone asked whether they thought they could keep up with the rapidly evolving ad ecosystem, and they said “well, this general approach works pretty well for spam filtering,” which I thought was telling—there is, after all, substantial overlap. They also said that they thought the same general approach would work for tracking protection but it would require its own classifier.

What Do Online Behavioral Advertising Privacy Disclosures Communicate to Users?

Online behaviorally-targeted advertising is often tagged with a little icon and/or short phrase which are hyperlinks to “landing pages” that talk about the behavioral targeting and may offer the opportunity to disable ad targeting (but not the associated behavioral tracking). This is part of an industry “self-regulatory” program which is supposed to make behavioral targeting more palatable. The study investigated what, if anything, these tags actually communicate to end-users, and how they react. Participants were shown a variety of ads, with between-subjects randomized tags, and then quizzed about what they thought the tags meant and what the landing pages communicated. Takeaways include:

• People mostly don’t even notice these tags.
• The icons used are meaningless, and most of the short phrases do not communicate that this is something clickable.
• After participants’ attention was drawn to the tags, more than half of them thought that clicking on them would cause more ads to pop up, increase ad frequency overall, and/or signal interest in the product currently being advertised. Some of the short phrases suggested an offer to buy advertising on the current website.
• The landing pages do not clearly make the distinction between disabling ad targeting (which is offered) and disabling behavioral tracking (which is not offered).

The speaker carefully avoided the elephant in this particular room, i.e. that advertisers are motivated to make their disclosure tags and landing pages as nonobvious and unfriendly as possible, because they don’t want people to disable behavioral ad targeting.

Changing of the Guards: A Framework for Understanding and Improving Entry Guard Selection in Tor

“Entry guards” are a designated subset of Tor relays that are considered reliable and probably-nonmalicious enough to use as entry nodes. The Tor directory authorities maintain a large list of potential entry guards; Tor clients pick a smaller set of nodes off the list, and route all circuits through them. (This is done to reduce the probability that the first relay in the chain will be malicious; a malicious entry node can do rather more damage to client anonymity than a malicious node later in the chain.)

This paper is an empirical investigation of how well this scheme works in practice, and whether it can be improved. They only have preliminary conclusions, but some of those are pretty telling: long-lived entry guards accumulate clients over time, and long-lived malicious nodes are likely to become guards. It’s unclear how to do better than the present set of heuristics, though.

I’m highlighting this paper as much because of its clever methodology as anything else: experiments were run entirely in simulation, but the simulated Tor network is configured to match the real network, according to the public relay directory. This seems like an effective strategy that could be applied to other sorts of network simulation experiments.

Tuesday

The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software

SSL (also known as TLS) is the most widely deployed implementation of the cryptosystem primitive known as a “secure channel,” which is supposed to deliver three security properties: confidentiality (nobody can eavesdrop on data in transit), integrity (nobody can modify data in transit), and authenticity (the transceiver at the other end of the channel is who you think they are). Authenticity is critical to real-world security, because the other two properties by themselves do not protect against a man-in-the-middle attack. (How does someone get to be in the middle, you might wonder? One popular technique is to load malware onto the local network hub, wireless router, etc.)

SSL provides authenticity via certificates of identity, which at least one side transmits for the other to “verify”, before communicating. Verification is a complicated process that must be done correctly or authenticity is lost. The point of this talk is that, while Web browsers (by dint of fifteen years of bug fixing) usually get certificate verification right, most of the other software that uses SSL has not had the benefit of fifteen years of bug fixes, and so frequently gets it wrong. They audited a wide variety of middleware libraries and applications, found lots of bugs, and make the strong claim that basically all non-browser SSL-using applications are insecure against an active man-in-the-middle attack.

Why so terrible? Well, the authors blame the ridiculous complication of both the certificate scheme itself, and the library APIs involved. One worked example stuck with me: Amazon Payments provides a client library in PHP. That code calls into a C library (libcurl) which calls another C library (libssl) to perform the actual crypto. libssl has dozens of options, all of which are faithfully reflected up through libcurl to the PHP bindings that the Amazon Payments library uses. Many of those options are intended only for debugging, but the author of the Amazon code zealously set them all, and set one of them to a value that defeats security, without realizing it.

Why Eve and Mallory Love Android: An Analysis of Android SSL (In)Security

On the same theme as the previous talk: Android’s stock runtime libraries implement certificate validation correctly. What could possibly go wrong? Well, you can disable validation, and lots of people have found it easier to disable validation than to arrange for their servers to have good certificates all the time. They analyzed 13,500 apps from the Android Market and found just over 1000 instances where validation had been disabled. A manual audit of a smaller set of apps found 41 out of 100 made some kind of related mistake which also destroys security. They demoed injecting a malicious update to a virus scanner’s signature base, causing the scanner to detect itself as malware and delete itself.

They didn’t talk at all about why this happens, I would speculate it’s an operational problem at root, rather than a coding mistake. Not only are certificates ridiculously complicated, getting them and deploying them to all the necessary servers is difficult. If you’re an app developer and you’re under time pressure and your company’s sysadmins are taking forever to get around to setting up the server correctly… disabling verification may be the path of least resistance.

Routing Around Decoys

Decoy routing is a scheme for censorship evasion, in which the end-user’s machine sends out traffic overtly intended for an innocuous site; routers somewhere in the backbone are programmed to notice a covert message in that traffic, and divert it to the censored site that the user actually wanted. This paper points out that the adversary in this scheme is normally in control of the routing infrastructure for the evasive user’s AS and can therefore control how that user’s packets get routed. This allows them to pull a variety of TCP-level tricks to detect decoy routing, and then disrupt it simply by choosing BGP routes that don’t go through the decoy routers.

Thus, for decoy routing to work, there have to be a bunch of important overt destinations that are completely behind decoy routers, from the censorious AS’s perspective. Running the numbers for the usual suspect ASes indicates that you have to get an impractically huge number of backbone providers to deploy decoy routers.

Wednesday

Operating System Framed in Case of Mistaken Identity

This is a modern user study on one of the oldest problems in the computer security book: If you are prompted to type your password, how do you know that the program prompting you is entitled to know your password? In addition to the well-known “phishing sites” that try to steal credentials for a particular site, malware is known to try to steal local account passwords in hopes that they are also passwords for high-value online services. The user study presented itself (to MTurk users) as an opinion poll of various online games, but one of the games in the sequence reported a missing browser plugin and popped up a fake OS installation-permission dialog, prompting for an administrative password. The visual deception was not perfect (notably, Windows always dims out the rest of the screen when it puts up a legitimate request for administrative credentials, which is impossible to fake from inside a webpage) but it appears that the majority of participants did not notice. It’s unclear how many people were genuinely deceived, since of course there is no way for the experimenters to tell whether any password entered was real. Only 20% of participants admitted to having typed in a real password, but the majority of participants claimed to have thought the prompt was real, and rejected the request on other grounds (e.g. not wanting to install plugins).

No solutions are offered, but considering how old and thorny this problem is, we can’t really complain.

The Devil is in the (Implementation) Details: An Empirical Analysis of OAuth SSO Systems

OAuth is a widely adopted federated authentication scheme. It’s quite complicated, and the 2.0 revision is even more complicated, to the point where its spec editors are quitting in disgust. Its security depends, of course, on implementation correctness.

This study did a deep dive on a hand-picked set of very popular websites that use OAuth (“if these guys get it wrong, what can we expect for everyone else?”) and find all kinds of security-breaking errors. 32% of the “relying parties” in their study are vulnerable to a network eavesdropper stealing an access token (which are not supposed to be sent to the relying site in cleartext, but people do it anyway; site developers may be under the misapprehension that OAuth makes SSL unnecessary). 64% of RPs mis-use public identifiers (e.g. Facebook account IDs) as credentials, allowing impersonation by anyone who knows the public identifier. And nearly all RPs have inadequate defense-in-depth against an XSS exploit stealing access tokens (it is not clear to me whether this is a flaw in the relying sites, or in OAuth itself; successful XSS is generally considered game over anyway, but if this allows an attacker to escalate a credential for one site into a pluripotent single-sign-on credential, that’s much worse.

They didn’t have time to go into it in the talk, but the paper has a number of suggestions for how “identity providers” can improve their APIs so that it’s harder for RPs to get things wrong. I approve of this approach; I don’t know enough about the problem space to assess whether their particular suggestions are helpful.

Strengthening User Authentication through Opportunistic Cryptographic Identity Assertions

This proposes a better user experience for two-factor authentication using a smartphone as a second factor. Right now some sites (notably Google) will send you a text message with a numeric code you type back into the site, or else offer an application that shows you a numeric code that changes every minute, which again you have to type in. Instead, they propose to have the computer talk directly to the phone over unpaired Bluetooth, eliminating all user actions after pressing “login”. Bluetooth is notoriously slow but they claim that it is still faster than reading the number off the phone and typing it in, and regardless it seems like it would be a more pleasant user experience. However, I couldn’t tell you which of my computers actually speak Bluetooth, and if you were on a machine with an old browser you might be hosed.

Question from the audience: don’t most people leave Bluetooth off all the time because it drains the batteries? Answer: dunno, hasn’t that been fixed by now?

Touching from a Distance: Website Fingerprinting Attacks and Defenses

“Fingerprinting attacks” have been around for a while. The game is, suppose a victim loads a website via an anonymizing service, which provides an encrypted channel to a generic IP address. An attacker sees all the traffic on the encrypted channel, but can’t read it and can’t observe its ultimate destination. (Whether the anonymizing service is a simple proxy or a mix network is moot, because the attacker is snooping directly on the victim.) Can the attacker still deduce what website is being visited? Maybe. The attacker can still observe the size and direction of each packet, and the inter-packet interval for each pair of packets, so the idea is to record the patterns of packets generated by known page loads, then try to match those against traffic going to the anonymizing service. Most of the literature only uses packet size and direction. Per-page accuracy in the 60-80% range, within a “closed world” of 100 to 2000 pages (almost always site front pages), is considered good.

This paper tries to improve fingerprint accuracy for individual pages by using Damerau-Levenshtein edit distance as the distance metric for a support vector machine, but the more interesting idea in the paper (unfortunately not covered in the talk) is to use hidden Markov models to generalize from individual pages to entire sites. If the victim is looking at a particular page, it’s more likely that they will load one of its outgoing hyperlinks next. The attacker builds a hidden Markov model of each site of interest, and uses it to predict a “typical” pattern of page loads, which in turn adjusts the per-page classifiers’ thresholds.

Thursday

You Are What You Include: Large-scale Evaluation of Remote JavaScript Inclusions

Problem statement: We know cross-site inclusion of JS is ubiquitous; who is trusted to provide JS libraries? How hard would it be to attack a JS library provider? Are there attack vectors that are non-obvious?

They give a few examples of actual exploits of JS library providers, then move on to an analysis of a 3.3-million-page JS-aware web crawl, within which they find 300,000 unique scripts loaded from 20,000 remote hosts. There is, unsurprisingly, a Zipf-ish distribution of script popularity. Five of the ten most-frequently-included scripts belong to Google and another three belong to “behind the scenes” analytics agencies that are invisible to end users. (The remaining two are the Facebook and Twitter APIs.)

Common, exploitable errors include:

• Requesting JS from “localhost”, i.e. the host running the browser, often on high port numbers. Malware can take advantage of this to mount attacks on sites, even in the presence of local privilege barriers (e.g. a malicious Android app normally cannot poke the browser).
• Similarly, requesting JS from private IP space—now the malware just has to be on the same network as the browser.
• Requesting JS from a site whose domain registration has expired; anyone could reregister it.
• Similarly, requesting JS from a mistyped domain (they gave the example of googlesyndicatio.com with the final ‘n’ left off) or from an IP address that has been reassigned.

They also pointed out that coarse-grained sandboxing won’t help because the intended scripts need too many privileges, and that it’s unusual for the scripts to change more often than once a week, so maintaining local copies might be feasible, given sufficient operational will and manpower.

Scriptless Attacks—Stealing the Pie Without Touching the Sill

This paper demonstrates a variety of XSS-style attacks that don’t require any scripting at all, bypassing existing XSS filters, CSP, NoScript—some even work in HTML-enabled mail readers. (This is your periodic reminder that nobody should ever send or accept HTML in email.)

The attacks, in general, work by exploiting some other feature of the Web platform that can conditionally trigger tailored requests to a malicious server: even when scripting is unavailable, it may be possible to inject these features. HTML form validation can be applied to hidden form fields and can trigger URL loads if regular expressions match. Invisible SVG files can use <set> elements to capture keystrokes (this is the one that works in Thunderbird). Custom fonts (using SVG, or OpenType’s discretionary ligatures) can control the size of the viewport, which together with media queries, can trigger URL loads. (This one seems a bit too baroque to be practical, but you never do know with these things.)