Going for the pipe spray is a kinda weird technique, and I'm honestly surprised that it worked. Usually just the fact that you are able to spray over the allocation at all isn't enough, and you also have to worry about your sprayed data containing additional pointers or things that also have to be valid.
I probably would have gone for turning the UaF into an type confusion style attack: if you spray more sockets you'll end up with two files, the original and the new one, that have aliased sk members, but the vsock code will incorrectly cast the new one to a `vsock_sock`. From there you can probably find some other socket type that puts controllable data over some field that vsock treats as a pointer or vice versa, and use it as both a kaslr leak and data-only r/w primitive.
> I probably would have gone for turning the UaF into an type confusion style attack
I'm aware that Linux is nearly 40 years old at this point, and C is even decades older. But it is mind-boggling to me that we're still talking about UAFs and jumping from dangling pointers to get privileged executions in the 21st century.
That was obvious to C.A.R Hoare in 1980, should have been obvious to the industry after the Morris worm in 1988, yet here we are, zero improvements to the ISO C standard in regards to prevent exploits in C code.
Nonsense, the C guy told me those happen to people that make mistakes, and that he, being the offspring of the Elemental of Logic, and "Hyperspace cybernetic intelligence and juvenile delinquent John Carmack" is completely immune to such pathetic issues. He works at Linux. Yes, all of Linux.
The last version of C is ISO C 23. I also do believe that rewriting in Rust is the best way to address memory safety in legacy C code and not even for new projects, nor do I think that memory safety is the most pressing security problem.
One thing that really annoys me about the HTTP standards is that some older version used to say that text/* without a declared charset was definitely latin-1 (don't remember which version exactly). Then a later version said no, text/* without a declared charset is definitely utf-8. In practice I feel this means they said "not declaring a charset is definitely not ok", but in a way that no one will understand.
Possibly a newer version that I haven't read fixed how they said that. As long as I don't check I can hope.
I really liked the old German university concept, the one before we just took over Bachelor/Master.
Throughout my CS studies, I was just collecting "tickets" (very hard to translate the actual word, "Schein"), which basically just attested that you have passed a course. They (often) had a grade on it, but it did not matter. Instead, once in the middle ("pre-diploma") and once at the very end of your time at university, you'd have oral exams. And those determined your grade. To attend them, you needed the right combination of "tickets".
The glaring downside of this system is that if you had a bad time in those few months of your very final exams, you could screw up your entire grade.
The upside of it, is that I was free (and encouraged) to pursue whatever I wanted, without each course risking to have an effect on my "GPA". I had way more tickets than I needed in the end, and still time and energy to pursue whatever else I wanted (playing with microcontrollers etc.).
I had a couple of classes in USA uni that worked quite similarly. The professor said we can take the quizzes if we want, and if we didn't then the later quizzes would constitute more of your grade. The ultimate play was to only take the final quiz.
> Throughout my CS studies, I was just collecting "tickets" (very hard to translate the actual word, "Schein"), which basically just attested that you have passed a course. They (often) had a grade on it, but it did not matter. Instead, once in the middle ("pre-diploma") and once at the very end of your time at university, you'd have oral exams. And those determined your grade. To attend them, you needed the right combination of "tickets".
What you are describing was one of the systems they used.
So at my university (OvG in Magdeburg) they used this system for math, but computer science had written exams.
This is an apples-oranges comparison, unless things have changed drastically since the last time I worked on L4 (about 10 years ago). L4 is very secure and easy to reason about. But that's because it doesn't really do anything. It makes a lot of sense as a platform to build a general purpose OS on, and as a bottom layer for what would otherwise be a unikernel. But you'd run a browser on top of something that itself runs on seL4, not on seL4 itself.
That's kind of the point, though. Naturally, a consequence of moving functionality out of the kernel and into userspace is that the kernel does less. That means rethinking the idea of how we build software (WRT what an OS means and what a platform API looks like), but on the other hand our current mode of building software is objectively dogshit, so that's no great loss.
It's becoming more and more common to use non Linux based hypervisors to isolate workloads where security matters. Isolating applications within a given VM is not seen as important and therefore ditching Linux isn't really necessary. Applications can continue to be written against Linux APIs and we can create isolation domains separately. This is no longer just a server concept as even phones and cars are starting to employ this technique. It has high cost to RAM, but as RAM gets cheaper it's not as big of a deal.
The obvious question is why Linux is so widely used in the first place. I don't think "APIs" is enough to explain it. One obvious answer is the incredibly broad hardware support. Any alternative selected for use as the hypervisor is going to be at a serious disadvantage in that regard.
Readit News
I probably would have gone for turning the UaF into an type confusion style attack: if you spray more sockets you'll end up with two files, the original and the new one, that have aliased sk members, but the vsock code will incorrectly cast the new one to a `vsock_sock`. From there you can probably find some other socket type that puts controllable data over some field that vsock treats as a pointer or vice versa, and use it as both a kaslr leak and data-only r/w primitive.
I'm aware that Linux is nearly 40 years old at this point, and C is even decades older. But it is mind-boggling to me that we're still talking about UAFs and jumping from dangling pointers to get privileged executions in the 21st century.
(rewrite it in Rust)
Deleted Comment
Looks like we've got an encoding issue too.
The document itself also lacks a declared character set.
Possibly a newer version that I haven't read fixed how they said that. As long as I don't check I can hope.
You should pretty much always use one.
Amazing! Sacrificing GPA for projects is always a good time
Throughout my CS studies, I was just collecting "tickets" (very hard to translate the actual word, "Schein"), which basically just attested that you have passed a course. They (often) had a grade on it, but it did not matter. Instead, once in the middle ("pre-diploma") and once at the very end of your time at university, you'd have oral exams. And those determined your grade. To attend them, you needed the right combination of "tickets".
The glaring downside of this system is that if you had a bad time in those few months of your very final exams, you could screw up your entire grade.
The upside of it, is that I was free (and encouraged) to pursue whatever I wanted, without each course risking to have an effect on my "GPA". I had way more tickets than I needed in the end, and still time and energy to pursue whatever else I wanted (playing with microcontrollers etc.).
What you are describing was one of the systems they used.
So at my university (OvG in Magdeburg) they used this system for math, but computer science had written exams.
"Never let school limit your education"
Deleted Comment
Deleted Comment
It's about time to look at a sane design, such as seL4[0].
https://sel4.systems/About/seL4-whitepaper.pdf
Deleted Comment