Weekend away with the other half in the convertible. No kids, no dogs. Driving round the north east of Engerland, which means a four hour drive there tonight and back on Sunday. Not looking forward to that, but the rest of the driving should be pretty ace.
Also visiting Lindisfarne (island) which means heading over a causeway and risking being cut off by the tide. I think I’ve been before as a small child but I don’t remember, so that’ll be a new (to me) experience!
Trying not to think about the fuel bill. It’ll be worth it for the experience.
Lindisfarne is lovely! I go there a lot, as it’s about 15 minutes away from me. Please do check the tide tables! Pilgrim’s Cafe is nice, and the vegan ice cream from next door is great too.
I’ve gotta work this weekend, so this is what I’m planning on:
I just started writing a permissively-licensed open source encrypted sockets library that enforces use of TLSv1.3 (and above, whenever that’ll happen) by using LibreSSL’s libtls. I plan to finish the core bits of that library.
I’m going to integrate the above project into all our networked applications.
For HardenedBSD:
I’m working on forcing -ftrivial-auto-var-init=zero to be enabled by default in clang. I’ve got a candidate patch ready for testing, which is my next goal. I plan to expand testing to arm64 this weekend.
For ${REAL_LIFE}:
I haven’t biked (of the pedal variety) seriously for the past five years. 2018-2020 hit me hard, then I switched jobs and became incredibly busy. I’ve made it my goal to bike when running errands, only using my car for the occasional work commute up to Baltimore (around once or twice per month) and to take my dog to various state parks (like Patapsco). So I’m going to increase the distance I bike each day by at least a half mile. Today, I did 4.5 miles, so hopefully tomorrow will be a full five miles.
I’m hoping to take my dog Vader on a little bike ride as well, perhaps a few times around our little neighborhood.
I’m working on forcing -ftrivial-auto-var-init=zero to be enabled by default in clang. I’ve got a candidate patch ready for testing, which is my next goal. I plan to expand testing to arm64 this weekend.
Be careful with default initialisation to zero. It’s usually a good idea but UNIX has one feature that makes it somewhat dangerous: the most powerful UID is zero. Most UIDs are unassigned and so there’s a high probability that an uninitialised UID field somewhere will contain random nonsense and generate an error, whereas zero initialisation will always hit root and allow things to run at the highest privilege level. There was one high-profile vulnerability last year that had exactly this root cause (initialising a structure with zeroes and forgetting to set the uid field).
I’d love to make the root UID a random value determined on first boot but there’s enough *NIX code out there that does if (getuid() == 0) that it’s probably hard to deploy.
You also have the intdescriptors. In a similar vein and frequent offender:
``if (-1 != mystruct.fd)
close(mystruct.fd);
With default to zero you can end up accidentally hitting STDIN_FILENO and then have it quickly being filled with something else thanks to the sparse allocation requirement. That one have hurt me enough times through buggy libs and, worse, python like runtimes that it’s very high up on the troubleshooting list.
On personal / testing rigs I tend to run with patches that randomises file-descriptor allocation, and libc that remaps stdio descriptors to higher values, with a trap device mapped to 0,1.
On personal / testing rigs I tend to run with patches that randomises file-descriptor allocation, and libc that remaps stdio descriptors to higher values, with a trap device mapped to 0,1.
That’s very interesting, does much stuff break? I’d expect a lot of stuff to have hard-coded file descriptors 0, 1, and 2. Since dup2, there’s very rarely a valid reason for closing stdin, so I guess you could have a test in the close function in libc that aborts if you try to do close(0) and do the raw syscall (or have a closestdin() wrapper) for the few cases if you actually need it.
Quite a lot breaks, so allow-lists are necessary or going slightly less aggressive and do what you said and go for close(0), … Now I’m in the unusual position that much of the user space runs things I have written or at least patched, but even then it is tedious.
The worst offenders tend to be shell scripts (2>1 and so on) and eccentric TUIs - isatty(0) leading to SSH trying to grab /dev/tty raw for password prompt input or gdb injecting quit into its prompt. Many raw C applications do avoid working directly against the descriptor for stdio though, the FILE abstraction comes earlier in people’s programming journey than all the nuances of write et al.
It is also interesting how some kernels or libc tries to protect you a bit: forking, closing then execing tends to give you /dev/null mapped into the slots rather than having it propagate. I vaguely member this not always being the case, but that might be dementia talking - faint memories of closing then execing to a suid binary that opens argument controlled input files and corrupting by finding some fprintf(stderr, “caller controlled log go here”). A notable exception that I found by fooling around was Linux proc/sys/kernel/core_pattern. The process it can spawn is quite unlike any other, including (1,2) not being mapped.
For avoiding sandbox escape shenanigans having the first few opens being unpredictable is a nice party trick still – normally you can assume something like a d-bus or wayland socket getting mapped to something static (3 or so) when writing your shellcode as their idiomatic use tend to come like main: parse_arguments(); open_ipc() -> 3. Without such assumptions you suddenly need to probe, and that is a lot more annoying and error prone than write(3, payload, payload_sz).
Do you have any idea how many things hard-code constants versus using STDIN_FILENO and friends? I wonder if redefining those to call a function that returned them (possibly a static inline function that calls a slow-path if some global is -1 and returns it otherwise) would help with compatibility. I’d love to be able to do this in production because there’s also a significant performance win from not requiring the first-open behaviour.
I’m not sure if there’s a good way of fixing 2>1 in the shell, though my initial thought with the standard file descriptors was to store them in ELF aux args. I wonder if it would be possible for the kernel to allow the parent to set up fds in fixed locations and then randomise their locations and provide their final locations via aux args so that libc could find them easily.
Do you have any idea how many things hard-code constants versus using STDIN_FILENO and friends?
Alas no, only useless empirical knowledge. This feels like a job for CodeQL.
Redefining those to call a function that returned them (possibly a static inline function that calls a slow-path if some global is -1 and returns it otherwise) would help with compatibility.
Do I hear the sound of prctl/procctl taking another one for the team? :-)
The compromise of letting 0, 1, 2 stay intact and drop the sparse allocation requirement thereafter might be a slightly less broken possibility than the horrors that mentally unpacking ‘file descriptor relocations’ as a concept would entail. Otherwise having a translation table for this most evil of namespaces in aux seems like a lovely new footgun to the collection, and I do love footguns more than feet. I wonder how bad the closefrom() / close_range() situation would suddenly get.
Do I hear the sound of prctl/procctl taking another one for the team? :-)
I think it would have to be.
The other thing on my to-do-eventually-hopefully list is a process-creation API that makes FD inheritance more explicit. If (for an example that probably isn’t quite what I want to build) execve took an array of file descriptor numbers, just as it took an array of arguments and an array of environment variables (the two other bits of state that are inherited from the parent) then it would be trivial for it to randomise their locations and then provide an aux args vector containing their new locations, which libc could then pick up. It would even be possible for rtld / csu to pick some of them up and write them into memory that’s read-only after the first user code is called, so variables like STDIN_FILENO could be initialised once and made read-only. This would also eliminate the need for closefrom to avoid inheriting FDs accidentally: if they’re not on the list, they’re not inherited past execve.
I haven’t really pushed on this because I presumed that the assumptions about file descriptors were entrenched in *NIX software, you’ve given me a bit more hope.
Hoping to learn Glamorous Toolkit / Smalltalk with a project around reporting potholes to my city. I want to extract EXIF data from pictures and upload details to a web form.
Finally, completed first version of Vim Reference Guide this week. Been catching up to pending tasks like r/fantasy 2021 bingo card, going through todo lists, etc. I’m also trying out recording short videos based on contents of the Vim guide.
Planning to re-read The Siege of Skyhold in preparation for beta reading the next one in the series.
I’m honestly not quite sure, which isn’t often the case.
I’ve needed a little de-comp, so for the past couple weeks I’ve done very little and stuck to small lifts when I did. But I’m starting to feel the itch. Some combination of:
nothing
fix my backup script, which has been broken for a little bit due to a substantive authentication API change
figuring out how resholve should handle intra-package executable invocations. I’ve been avoiding the decisions/assumptions necessary to do it, but I ran into some real-world examples this Winter and may be able to do better than guess, now.
I’m honestly not quite sure, which isn’t often the case.
I have that too sometimes, like from the moment I wake up I know there’s going to be nothing interesting today which makes me feel bad since I like being active.. What do you do during that?
I feel like most days I know what’s now (and what’s next, if I’m almost done with something).
Often when I don’t (or when I know, but I nonetheless am not motivated to act) it’s ultimately about uncertainty or indecision. This might be broad uncertainty about what to prioritize (i.e., there are a few equally-plausible things to do next, I’ve actually burned the list down to the point where there’s nothing critical, what’s important is in conflict with what’s interesting, etc.), or it might be narrow uncertainty about how to implement something. I might figure it out quickly, or I might be stuck in the doldrums for a few days first.
If I’m highly motivated to be making progress, this condition can get frustrating quickly. It’s good to go pick something unrelated and work it, even if that’s just something ~dull like cleaning or doing taxes or reading enough product reviews to pick a new frobulator.
If I’m not feeling motivated, it’s usually best to just embrace it. Watch some movies/TV, read some books, go for a long walk, sit under a tree, watch clouds float by, etc.
This week I finished a small tool to help me learn the number in Korean. I shared it among my classmates and got some feedback to improve the UX, so I will spend some time this weekend fixing stuff.
Weekend away with the other half in the convertible. No kids, no dogs. Driving round the north east of Engerland, which means a four hour drive there tonight and back on Sunday. Not looking forward to that, but the rest of the driving should be pretty ace.
Also visiting Lindisfarne (island) which means heading over a causeway and risking being cut off by the tide. I think I’ve been before as a small child but I don’t remember, so that’ll be a new (to me) experience!
Trying not to think about the fuel bill. It’ll be worth it for the experience.
Lindisfarne is lovely! I go there a lot, as it’s about 15 minutes away from me. Please do check the tide tables! Pilgrim’s Cafe is nice, and the vegan ice cream from next door is great too.
Ah thanks, it’s an organised run by someone that lives up that way and has paid attention to such details so we shouldn’t get caught out.
I’ve gotta work this weekend, so this is what I’m planning on:
For HardenedBSD:
I’m working on forcing
-ftrivial-auto-var-init=zero
to be enabled by default in clang. I’ve got a candidate patch ready for testing, which is my next goal. I plan to expand testing to arm64 this weekend.For ${REAL_LIFE}:
I haven’t biked (of the pedal variety) seriously for the past five years. 2018-2020 hit me hard, then I switched jobs and became incredibly busy. I’ve made it my goal to bike when running errands, only using my car for the occasional work commute up to Baltimore (around once or twice per month) and to take my dog to various state parks (like Patapsco). So I’m going to increase the distance I bike each day by at least a half mile. Today, I did 4.5 miles, so hopefully tomorrow will be a full five miles.
I’m hoping to take my dog Vader on a little bike ride as well, perhaps a few times around our little neighborhood.
Be careful with default initialisation to zero. It’s usually a good idea but UNIX has one feature that makes it somewhat dangerous: the most powerful UID is zero. Most UIDs are unassigned and so there’s a high probability that an uninitialised UID field somewhere will contain random nonsense and generate an error, whereas zero initialisation will always hit root and allow things to run at the highest privilege level. There was one high-profile vulnerability last year that had exactly this root cause (initialising a structure with zeroes and forgetting to set the uid field).
I’d love to make the root UID a random value determined on first boot but there’s enough *NIX code out there that does
if (getuid() == 0)
that it’s probably hard to deploy.You also have the intdescriptors. In a similar vein and frequent offender:
``if (-1 != mystruct.fd) close(mystruct.fd)
;
With default to zero you can end up accidentally hitting STDIN_FILENO and then have it quickly being filled with something else thanks to the sparse allocation requirement. That one have hurt me enough times through buggy libs and, worse, python like runtimes that it’s very high up on the troubleshooting list.
On personal / testing rigs I tend to run with patches that randomises file-descriptor allocation, and libc that remaps stdio descriptors to higher values, with a trap device mapped to 0,1.
That’s very interesting, does much stuff break? I’d expect a lot of stuff to have hard-coded file descriptors 0, 1, and 2. Since
dup2
, there’s very rarely a valid reason for closing stdin, so I guess you could have a test in theclose
function in libc that aborts if you try to doclose(0)
and do the raw syscall (or have aclosestdin()
wrapper) for the few cases if you actually need it.Quite a lot breaks, so allow-lists are necessary or going slightly less aggressive and do what you said and go for close(0), … Now I’m in the unusual position that much of the user space runs things I have written or at least patched, but even then it is tedious.
The worst offenders tend to be shell scripts (2>1 and so on) and eccentric TUIs - isatty(0) leading to SSH trying to grab /dev/tty raw for password prompt input or gdb injecting quit into its prompt. Many raw C applications do avoid working directly against the descriptor for stdio though, the FILE abstraction comes earlier in people’s programming journey than all the nuances of write et al.
It is also interesting how some kernels or libc tries to protect you a bit: forking, closing then execing tends to give you /dev/null mapped into the slots rather than having it propagate. I vaguely member this not always being the case, but that might be dementia talking - faint memories of closing then execing to a suid binary that opens argument controlled input files and corrupting by finding some fprintf(stderr, “caller controlled log go here”). A notable exception that I found by fooling around was Linux proc/sys/kernel/core_pattern. The process it can spawn is quite unlike any other, including (1,2) not being mapped.
For avoiding sandbox escape shenanigans having the first few opens being unpredictable is a nice party trick still – normally you can assume something like a d-bus or wayland socket getting mapped to something static (3 or so) when writing your shellcode as their idiomatic use tend to come like main: parse_arguments(); open_ipc() -> 3. Without such assumptions you suddenly need to probe, and that is a lot more annoying and error prone than write(3, payload, payload_sz).
Do you have any idea how many things hard-code constants versus using
STDIN_FILENO
and friends? I wonder if redefining those to call a function that returned them (possibly astatic inline
function that calls a slow-path if some global is-1
and returns it otherwise) would help with compatibility. I’d love to be able to do this in production because there’s also a significant performance win from not requiring the first-open behaviour.I’m not sure if there’s a good way of fixing
2>1
in the shell, though my initial thought with the standard file descriptors was to store them in ELF aux args. I wonder if it would be possible for the kernel to allow the parent to set up fds in fixed locations and then randomise their locations and provide their final locations via aux args so that libc could find them easily.Alas no, only useless empirical knowledge. This feels like a job for CodeQL.
Do I hear the sound of prctl/procctl taking another one for the team? :-)
The compromise of letting 0, 1, 2 stay intact and drop the sparse allocation requirement thereafter might be a slightly less broken possibility than the horrors that mentally unpacking ‘file descriptor relocations’ as a concept would entail. Otherwise having a translation table for this most evil of namespaces in aux seems like a lovely new footgun to the collection, and I do love footguns more than feet. I wonder how bad the closefrom() / close_range() situation would suddenly get.
I think it would have to be.
The other thing on my to-do-eventually-hopefully list is a process-creation API that makes FD inheritance more explicit. If (for an example that probably isn’t quite what I want to build)
execve
took an array of file descriptor numbers, just as it took an array of arguments and an array of environment variables (the two other bits of state that are inherited from the parent) then it would be trivial for it to randomise their locations and then provide an aux args vector containing their new locations, which libc could then pick up. It would even be possible for rtld / csu to pick some of them up and write them into memory that’s read-only after the first user code is called, so variables likeSTDIN_FILENO
could be initialised once and made read-only. This would also eliminate the need forclosefrom
to avoid inheriting FDs accidentally: if they’re not on the list, they’re not inherited pastexecve
.I haven’t really pushed on this because I presumed that the assumptions about file descriptors were entrenched in *NIX software, you’ve given me a bit more hope.
Hoping to learn Glamorous Toolkit / Smalltalk with a project around reporting potholes to my city. I want to extract EXIF data from pictures and upload details to a web form.
Getting a COVID test to prepare for some travel, then hopefully going skiing?
Finally, completed first version of Vim Reference Guide this week. Been catching up to pending tasks like r/fantasy 2021 bingo card, going through todo lists, etc. I’m also trying out recording short videos based on contents of the Vim guide.
Planning to re-read The Siege of Skyhold in preparation for beta reading the next one in the series.
I’m honestly not quite sure, which isn’t often the case.
I’ve needed a little de-comp, so for the past couple weeks I’ve done very little and stuck to small lifts when I did. But I’m starting to feel the itch. Some combination of:
All of the above, hopefully :)
I did quite well at the first 2, and at least started sketching out the tensions that are making me indecisive about the third. :)
I have that too sometimes, like from the moment I wake up I know there’s going to be nothing interesting today which makes me feel bad since I like being active.. What do you do during that?
Hmm. Not sure this quite fits what you mean, but…
I feel like most days I know what’s now (and what’s next, if I’m almost done with something).
Often when I don’t (or when I know, but I nonetheless am not motivated to act) it’s ultimately about uncertainty or indecision. This might be broad uncertainty about what to prioritize (i.e., there are a few equally-plausible things to do next, I’ve actually burned the list down to the point where there’s nothing critical, what’s important is in conflict with what’s interesting, etc.), or it might be narrow uncertainty about how to implement something. I might figure it out quickly, or I might be stuck in the doldrums for a few days first.
If I’m highly motivated to be making progress, this condition can get frustrating quickly. It’s good to go pick something unrelated and work it, even if that’s just something ~dull like cleaning or doing taxes or reading enough product reviews to pick a new frobulator.
If I’m not feeling motivated, it’s usually best to just embrace it. Watch some movies/TV, read some books, go for a long walk, sit under a tree, watch clouds float by, etc.
Earlier in the week I put down a deposit on a new guitar in a music store in a nearby town, and going there to try it out on Saturday :-)
Good question! Maybe I’ll finally get generics working in my type checker. Chances don’t seem high though.
RPGs, on- and offline.
Celebrate a milestone of intermittent fasting.
This week I finished a small tool to help me learn the number in Korean. I shared it among my classmates and got some feedback to improve the UX, so I will spend some time this weekend fixing stuff.
Wanted to try out using Remix Blues Stack and build my personal site with it.