31–40 of 55 posts
Takes some dedication to still be using CVS. Do they use another version control system to feed into CVS, or is CVS the tool they use directly?
Earlier quoted context omitted.
How would you measure that? How would you notice a failed attempt at finding a hole, of stack smashing, etc, if it did not even result in a crash, or any other dysfunction? Not a rhetorical question.
I suppose if someone found a technique in the wild that defeats regular ASLR (even if only sometimes), they could then test that same technique against fine-grained ASLR and evaluate if the FG ASLR was more effective at preventing exploitation.
Maybe take a known vulnerable exec, create a fuzzing attacker and run it both ways seeing how long it takes to get lucky a few times. The more secure version should take longer.
I remember how back in MS DOS days polymorphic viruses first appeared, in an attempt to avoid detection by antivirus software (useful and essential back then). Now the tables have turned, and legitimate software has to become somehow polymorphic to thwart attacks by malware.
I wonder if it is possible to make a relinker which only requires binary output -- so it could be easily incorporated into existing systems.
One way I can think of is to keep relocation/original object information in the debug sections, so that one can reconstruct original object files and re-link them. But I am guessing this will not work with LTO though... Or maybe we can just make a bunch of debug sections and store input object/library files verbatim -- this will at least double the binary size, but will allow for easier relinking.
In order to enable relinking, they had to keep around all original .o and .a files, as well as a Makefile. Not a problem for OpenBSD but pretty unusual for binary Linux distros. I wonder if it is possible to make a relinker which only requires binary output -- so it could be easily incorporated into existing systems. One way I can think of is to keep relocation/original object information in the debug sections, so th…
https://research.facebook.com/publications/bolt-a-practical-...
https://groups.google.com/g/llvm-dev/c/ef3mKzAdJ7U/m/1shV64B...
Earlier quoted context omitted.
I think I've got a better idea now. So openbsd has ASLR which affects data, code/library, and stack positions. Then this solution works on top of it by reordering symbols within the code. One thing I'm still not sure about is whether the kernel could theoretically do the same reordering at load time using relocatable symbols.
The assembler laid out the code within the sections and generally it's not changed after that (except for targets that do linker relaxation). However with -ffunction-sections the compiler would put each function in its own section which then can be independently relocated.
Takes some dedication to still be using CVS. Do they use another version control system to feed into CVS, or is CVS the tool they use directly?
So it looks like they are going to move on from CVS eventually.
Finally! At least, someone finally understands that static, fully predictable, reproduce-able-builds are only an convenience feature for the attacker side.
Sometimes it can be beneficial to optimize the link so most of the main thread stays in cache. Obviously this only really matters for CPU-intensive programs.