There’s a FreeBSD commit to telnet. fix a couple of snprintf() buffer overflows. It’s received a bit of attention for various reasons, telnet in 2019?, etc. I thought I’d take a look. Here’s a few random observations.

Here are three new lines, after the patch.

                unsigned int buflen = strlen(hbuf) + strlen(cp2) + 1;
		cp = (char *)malloc(sizeof(char)*buflen);
		snprintf((char *)cp, buflen, "%s%s", hbuf, cp2);

1. The first line is indented with spaces while the others use tabs.

2. The correct type for string length is size_t not unsigned int.

3. sizeof(char) is always one. There’s no need to multiply by it.

4. If you do need to multiply by a size, this is an unsafe pattern. Use calloc or something similar. (OpenBSD provides reallocarray to avoid zeroing cost of calloc.)

5. Return value of malloc doesn’t need to be cast. In fact, should not be, lest you disguise a warning.

6. Return value of malloc is not checked for NULL.

7. No reason to cast cp to char * when passing to snprintf. It already is that type. And if it weren’t, what are you doing?

8. The whole operation could be simplified by using asprintf.

9. Although unlikely (probably impossible here, but more generally), adding the two source lengths together can overflow, resulting in truncation with an unchecked snprintf call. asprintf avoids this failure case.

One of the basic objects in ActivityPub is the actor. Also known as a Person, although there’s no promise it’s a human. If you are building ActivityPub software, or curious how the network works, it’s a good place to start. The ActivityPub spec and underlying ActivityStreams vocabulary explain what could or should be here, but not necessarily what you’ll see in the wild.

more...

When a web page (or other resource) cannot be found, a web server is supposed to return code 404, Not Found. Additionally, it can return some other content for a human viewer. And so, if you visit https://mastodon.social/honktime](https://mastodon.social/honktime) with a browser, you can watch a tooter tantrum, but requesting the same URL with curl displays < HTTP/2 404.

more...

You’re out there posting on your federated status federator, and people are reading your posts, and you’re reading their posts, but how exactly does it happen? What’s talking to what? (Equally applicable to tooting, but we don’t use that word in my house.)

more...

There’s a new paper, From IP ID to Device ID and KASLR Bypass, which I liked. It’s at the intersection of networking, old but not obsolete standards, random, security, and implementation defined behavior. By all means, read the paper, but the really short version is they accomplished two things. They reverse engineered a per host random seed from network traffic on Windows and Linux, allowing fingerprinting, and more surprising, turned this into a KASLR break on Linux. Pretty wild.

more...

One of the unexpected but very interesting side effects of the brutalist html quine is that anything added to the page suddenly becomes visible as well. In the common case, this might be browser extensions adding custom stylesheets, but it might also be stylesheet or script injection by a network interloper.

What if every web page had a little something like this embedded in it?

That’s an actual style. It should be the only one visible on this page. If there’s anything else visible, it’s not coming from me.

It’s been a little while, so a few more notes about ActivityPub implementation, federation, and other odds and ends. There’s no real order to these notes, just things that have come up in the past two months.

more...

I’ve had an iPhone for many years, and an iPad for not quite as long. People would tell me I should switch to Android. I thought they were crazy. I recently got some Android devices. Now I know they are crazy. Some notes on recent experiences with a Moto G6 and Samsung Tab S5e.

more...

The wifi network at BSDcan, really the UOttawa network, blocks a bunch of ports. This makes it difficult to connect to outside machines using “exotic” protocols, basically anything except http or https. There are many ways to resolve this, here’s what I did.

more...

Common problem for operating system fuzzers is breaking the system they’re running on. Some forms of damage are expected, some are not, and sometimes it’s difficult to tell which is which.

A few days ago, a stack leak bug was fixed in FreeBSD. A similar fix for OpenBSD was committed. And then syzkaller came kalling just a few days later.

panic: bad dir

There’s a few possible causes for this, but inspection revealed that the most likely case might be a directory entry missing the nul terminator. The timing certainly seemed suspicious. Could there be an off by one?

memset(newdirp->d_name + (cnp->cn_namelen & ~(DIR_ROUNDUP-1)), 0, DIR_ROUNDUP);

Actually no. syzkaller had found a way to create filesystem corruption through one of the “expected” damage paths, but the test case was a little obfuscated. More study revealed it was calling mknod to create a new device that happened to be equal to /dev/sd0c and opening it, and then calling pwrite to write some garbage to a random spot.

mknod("banana", 0777, 0x0402);
open("banana")
pwrite(3, "oops", 4, 0x9000);

Not recommended.

Further complicating the matter was that syzkaller didn’t know that pwrite is one of the magic syscalls that takes a padding argument before off_t. This didn’t affect the test, per se, but makes it harder to interpret because syzkaller calls things directly. (The actual syscall in use was the iovec variant, pwritev.)

syscall(SYS_pwritev, r[0], 0x200002c0, 1, 0);

If you read the man page for pwritev that looks correct. But inspecting src/sys/kern/syscalls.master reveals that the fourth argument is actually a pad argument, and the offset is the fifth argument. So the call above was writing to an offset that was not zero.

Not the first fuzzer to encounter this oddity. More details here.

In the end, it was just coincidence that syzkaller found a new way to corrupt its filesystem a few days after a filesystem commit.