Progress, Technology, Culture
By Jade Wang - 17 Apr 2015
How does the technological development of a civilization relate to its culture?
At equilibrium, a society with safe, affordable and widely accessible forms of birth control has different cultural values from one that does not. A society with affordable, ubiquitous, and open Internet access will have different cultural values, productivity, and global impact on other cultures from one that does not. And of course, a society with ubiquitous smartphone cameras will hold its police officers more accountable for human lives than one that relies on human eyewitness testimony.
Ubiquitous. Widely accessible. Democratized. It is not enough for these technologies to simply exist; there is a limit to the impact of a technology that only the wealthy few percent can afford, and a limit on the pressure exerted on that culture to adapt to its new environmental conditions. There is something amazing, akin to a phase transition, that happens when each technology gets democratized past a certain point. It’s like the difference between a society with access to measles and polio vaccines and one that does not. It’s the efficiency of trade in a developing nation with infrastructure to support basic, affordable SMS service versus one that does not.
Those of us working in technology today would do well to keep these things in mind: we don’t just serve deep pockets, we serve humanity. Democratizing access to existing technology is just as important as creating new technology.
The cultural effects of widespread and democratized access to personal servers is left as an exercise for the reader.
- 2015: Why would ordinary people want a personal server?
- 1977: There is no reason for any individual to have a computer in their home.
- 1946: [Television] won’t be able to hold on to any market it captures after the first six months.
- 1905: Sensible and responsible women do not want to vote.
- 1878: This ‘telephone’ has too many shortcomings to be seriously considered as a practical form of communication.
- 1762: One half of the children born die before their eighth year. This is nature’s law; why try to contradict it?
Defining “progress” is also left as an exercise for the reader.
Let's Chat
By Jason Paryani - 13 Apr 2015
Last week, I packaged Let’s Chat, an open source team chat app, similar to Slack. You can try it on the Sandstorm demo right now, or install it from the app list.
As described by its developers:
Let’s Chat is a persistent messaging application that runs on Node.js and MongoDB. It’s designed to be easily deployable and fits well with small, intimate teams.
A few notes on the packaging process: This package doesn’t use the normal MongoDB, but instead Kenton’s fork. This allows the app to only use ~300KB of storage when each instance is created instead of the normal minimum of a few hundred MB for Mongo. Otherwise, the packaging process went very smoothly except for dealing with passport, a Node.js authentication library. I ended up forking passport-token to look at HTTP headers only (by default it will look at POST data as well, which would make it insecure inside Sandstorm). You can see the forked code here, and if there’s some interest, I can work to get it published on NPM.
You can see the full package source here, and if you want to use Let’s Chat, check it out on the app list. Feel free to let me know what you think on sandstorm-dev.
Remotely send Chrome and Node.js into infinite loops via this one weird OSX kernel bug
By Kenton Varda - 08 Apr 2015
A few months ago I discovered a security bug in the Darwin kernel used by most Apple products. The bug could allow an attacker to trivially remotely DoS a variety of network services and apps, from Node.js to Chrome. Today, Apple released a patch (look for CVE-2015-1105), so now I can tell you about it.
Now, just to be clear, I’m no Adam Langley. This bug is “just” a DoS, nothing like a Heartbleed or a Shellshock. The worst it can do is allow an attacker to cause a temporary service disruption. But I think all security bugs deserve a writeup so that we can learn from them, and Apple’s terse description of the problem doesn’t accomplish this. Also, it’s a fun story.
I discovered the problem while doing research on the different interfaces that various operating systems provide for doing event-driven I/O – that is, how you tell the platform: “Here are all my open connections; wake me up when one of them receives a message.” It turns out that every OS does this differently. Linux has epoll. BSD has kqueue. Windows has… well, about five different mechanisms that cover differing subsets of usecases and you can only choose one. In any case, I was trying to build an abstraction layer over these for Cap’n Proto, so I wanted to make sure I understood them all.
I noticed a curious thing: some man pages discussed an event called “out-of-band data” while others didn’t. “Out-of-band data” (OOB), also known as “urgent data”, is a little-used feature of TCP connections that essentially allows you to send a byte that “jumps the queue” so that the receiving app can receive it before receiving other data sent before it. You probably didn’t know about this, because basically no one uses this feature – except for Telnet, which needs a way to signal that you pressed “ctrl+C” when the destination app is not otherwise processing input.
With almost all event notification APIs, regular data and OOB data raise different kinds of events. For example, poll() (and its successor on Linux, epoll) has POLLIN for regular data and POLLPRI for OOB. This way, if your app does not expect to receive OOB data, it simply doesn’t ask to be notified about that type of event, and the kernel happily discards it for you (or maybe inserts it into the regular stream, which is fine).
Curiously, the BSD kqueue docs are unclear on how OOB data is handled. FreeBSD’s kqueue makes no mention of it, and as far as I’ve been able to determine it simply doesn’t support notification of OOB events at all. DragonflyBSD’s kqueue defines an EVFILT_EXCEPT event type.
Darwin’s (OSX/iOS) kqueue also doesn’t mention OOB data, but some Googling revealed an undocumented “feature”: on OOB data, Darwin will raise a regular EVFILT_READ event (which normally indicates that regular in-band data was received) but set the special flag EV_OOBAND on the event structure.
Of course, if you aren’t expecting OOB data, you’re not going to check for that flag. So when you receive EVFILT_READ, you’re going to believe you’ve received regular data. And you’re going to do a recv() call to read that data, and there isn’t going to be any. And then you’re going to say “oh well” and return to the event loop. But if you are using kqueue() in level-triggered mode (as most people do, because it’s easier), then the operating system is going to see that the OOB data is still there, and is going to give you the exact same event again.
So you go into an infinite loop.
Wait, doesn’t that mean almost all event-driven OSX network apps will go into an infinite loop if they receive a single TCP packet with the urgent bit set?
I didn’t think that could possibly be true at first, so I fired up a Mac machine to try it. Sure enough:
-
When Google Chrome visited an HTTP server that sent back an OOB byte, the whole app (not just the tab, but everything) locked up and had to be force-quit. It turns out Chrome does all networking from the main process, so the per-tab process separation did not help. (Chromium issue 437642 – currently still locked down as a security issue)
-
When a Node.js server received an OOB byte from a client, the server would go into an infinite loop and stop handling other connections. (fixed in this commit)
On the other hand, my third test case – nginx – was not affected, because it uses kqueue in edge-triggered mode, and therefore it only receives the unexpected event when new data arrives rather than any time data is available – i.e. once rather than infinity times. But two of three is a pretty worrisome hit rate, especially when these are some very big names.
Arguably the worst / most interesting part of this problem is that it was a problem inherent in the API. Technically it was not that the kernel was buggy, but that the interface was confusing (and underdocumented) in a way that caused the same bug to manifest in several different apps. Fixing the problem either required fixing every app (and being ever-vigilant in the future), or changing the API and breaking any existing app that depended on the behavior (of which there appears to be a few).
To Apple’s credit, they did what I think is the right thing: they changed the interface so that it no longer reports EVFILT_READ events on TCP OOB data. I do not quite understand their description of this problem as a “state inconsistency issue”, but my tests confirm that OOB data is now ignored.
The moral of the story? Confusing APIs are a security problem. If many users of your API get it wrong in a way that introduces a security bug, that’s a bug in your API, not their code.
See you at PyCon in Montreal this weekend
By Asheesh Laroia - 06 Apr 2015
I’m hoping to see you in Montreal at PyCon 2015! I’m co-speaking at a talk and a tutorial. I’ll also be eager to talk to people about Sandstorm and self-hosting servers.
Last year, I co-gave a talk about turning your computer into a server with Karen Rustad. Here’s what it looked like when one of my friends surprised me by changing the data we were showing during a live demo:
That Lol is supposed to say Django. Thanks, Luke. Check out my expression of amusement masking horror.
I got compromised because the Django sample app I demo’d has a default admin account bundled with it, as part of the demo. The good news is if you’re using Sandstorm, the platform handles authentication & authorization for apps, so this sort of thing won’t happen to you. Plus, as you would expect, Sandstorm ships with no default passwords.
This year I’m co-leading a tutorial called Getting Comfortable With Web Security where we discuss all sorts of common security issues with web applications; Jacky Chang and Nicole Zuckerman are my co-presenters. I’m also sharing a stage with Philip James to answer the question, Type python, press enter. What happens?
I hope to see you there! Doubly so if you’re interested in a Sandstorm & server self-hosting Birds of a Feather session. Send an email to asheesh@sandstorm.io!
Ruby on Rails Porting Guide
By David Renshaw - 30 Mar 2015
One positive side effect of my work on the GitLab app is that we now have a porting guide tailored specifically for Ruby on Rails. If you have a Rails app that you’d like to package for Sandstorm, this is the place to start. The guide should quickly get you up and running, and it explains how to deal with a few quirks that are particular to how Rails and Sandstorm interact.
I invite you to read it, to try porting an app, and to tell me what you think! I am by no means an expert on anything Ruby-related, so don’t hesitate to contribute corrections, either by directly editing the wiki, by starting a discussion on the sandstorm-dev mailing list, or by emailing me.