Implementing K/ASLR on unikernel (I)
ASLR becomes KASLR when you are working on unikernel environment.
During these holidays I'm having a great time trying to provide ASLR to a unikernel that we are going to use in our product ExploitChance (Grupo Pentest®) . The goal of this unikernel is to replace Linux in a system dedicated and very specialized to a specific task and I do not want our clients to ever have to worry about having to be on the lookout for Linux vulnerabilities. Therefore, a unikernel, with a very reduced source code base, allows us to have enormous control over the exposure area, in our case, the TCP/IP stack and the application that interacts with the outside world. There is nowhere else to scratch for an attacker. Even so, the unikernel we are working with did not implement ASLR (or KASLR because we are in kernel mode....) so it occurred to me to do that little security implementation job, which is so mythologized but which in reality is the most vulgar and simple thing that one can imagine once it is stripped of that halo of mysticism that everything that concerns cybersecurity has.
The problem seems simple: you have to provide randomness to the (different) memory addresses used to map both the code of the program that is executed and the processes. The reality of the implementation is a little more fun: since it is a unikernel, all the code is executed in kernel mode, so in reality we are talking about KASLR which implies that we have to provide randomness to the Heap, the Stack and the code of the (main) program (OS/Kernel), but of course, that randomness... where do we get it from...?
I had never stopped to think about that, when you work in user space, there is already a service that provides randomness, but when you are starting an operating system, and setting up everything (memory management, IO, file system, interrupts, etc. ) there is no such service that provides a source of randomness.
Recommended by LinkedIn
From what I have seen, here each operating system looks for life as best it can... In my specific case I found that the unikernel expected to obtain said source of randomness from external hardware or it generated an error... Taking into account that That is not something we have in mind in the short term (although in the medium term) it occurred to me to use some algorithm to generate pseudo random numbers... and I soon discovered that everyone expects to obtain a seed with random data to start... A fucking fish that bites its tail. I don't know what brain of an engineer or mathematician came up with this system, but it sucks. Anyway, how do you have to adapt, well I thought about obtaining said randomness from something physical in the operating system... let's see, what we have... damn, the CPU clock... I had just discovered the wheel...
Read the next article on this topic: