Every software project has a backlog of enhancement requests, unimplemented features. It may be explicitly tracked in a database, or perhaps just a sort of informal consensus among developers. Whether officially acknowledged or not, it exists.
more...
One way to slip malicious code into a project is to hack into their build server and just drop it in. Messy. Another way is to hack a trusted developer’s machine and alter the code there so that they commit it, but it might get spotted during code review. A third way is to become a developer, then yourself commit a seemingly innocuous patch containing an obfuscated backdoor. This is sneaky. Even better is to have somebody else intentionally commit the backdoor for you.
Consider this code to allocate some buffers.
void *
allocatebufs(int num)
{
size_t limit = 256;
if (num > limit)
return NULL;
return malloc(num * 64);
}This isn’t top quality code, but it’s totally safe and secure. It does however trigger a warning about signed vs unsigned comparisons. Many developers don’t like to see those. Some will even try to fix it.
void *
allocatebufs(int num)
{
size_t limit = 256;
if (num > (int)limit)
return NULL;
return malloc(num * 64);
}Now the warning is gone. And they’ve introduced a serious security hole.
If you’re a sneaky bastard, you might write the first code and submit it, knowing that a trusted developer somewhere down the line will alter it. And you’ve got perfectly plausible deniability. Your code was secure. They introduced the bug.
This is just a thought experiment, and you can dissect it with the razor of your choosing, but what I think is interesting is the paradox of plausibility. What happened? The most likely explanation is the mundane one, that it’s just an accident. People introduce bugs like this with alarming regularity. No reason to suspect foul play. But it’s the dependable regularity of such errors that make the attack possible. If people didn’t introduce bugs fixing harmless warnings, the attack would never succeed.
(There was a concrete incident, somewhat similar, although this is not meant to be a comment on any particular patch or fix.)
We’ve got the band back together and we’re ready to rock!
more...
There was a lot happening here. The summaries started getting really unwieldy. Just listing all the relevant names in some cases would stretch to several paragraphs. I’ve tried to streamline things a bit, but tons of great material has been cut out.
more...
gerc (good enough revision control) is a partial reimplementation of mercurial. Between got and bitbucket, it seems source control is back in the news. Here are some scattered notes about gerc and its development. It’s not complete or recommended for use, so don’t expect much.
more...
Two years ago, I read some books. It’s kind of hard to believe it’s been two years since then; I was sure it was only one year ago. Guess that means it’s time to try again. Reading five books seemed a little frantic at times, and two or three is probably a better pace for me, so this time I’ll be reading five books again.
more...
Times change and programs must change with them. Altering or removing functionality however risks breaking backwards compatibility. A few examples.
more...
If you’re looking to move beyond the silos of social media sites run by individual companies, you’re maybe looking for federation, which allows multiple sites to communicate and interoperate with each other. You post a photo on this site, your friends on another site can share it, your family on a third site can comment on it. Assuming that’s what you want.
more...
Some more notes about networking between federated ActivityPub servers. A brief overview covered a fairly typical exchange to transfer a post from one server to another. Here’s a few more details, how following works, and some more notes about addressing and delivery.
more...
So you have an ActivityPub actor and you want to say something. What are you going to post? Might I suggest a Note?
more...