On Tue, Feb 25, 2020 at 11:59 PM Gregory Nutt <spudan...@gmail.com> wrote: > > Hi, > >> > >>> i meant that, if userspace wants to read some kernel memory, it can pass > >>> the kernel pointer to eg. write system call as the buffer argument, > >>> and then read the contents of the file. > >> I guess I still don't understand. Access is still via file descriptor. > >> You could certainly clobber kernel memory with a read in that way. But > >> it is not clear how you could read the kernel memory into user space. > > Here is an example: > > Program open malicious elf and call read with a pointer to kernel > > stack, then kernel may run code from elf after kernel finish and > > return. > > It is not clear to me how you could do that. The stack is not > accessible to the calling thread while the system call is running, but I > suppose it could be accessed by another thread: > > 1. Thread A calls sem wait > 2. Thread B modifies Thread A return stack so that sem_wait returns to > user code, then posts the semaphoe > 3. When semaphore wakes up, the return would execute in supervisor mode. > > Unlike Linux (and most higher end OS's), NuttX does not use a separate > kernel stack. In Linux, each task has two stacks, a user space stack > and a kernel space stack. In the system call handler, it switches ti > the kernel stack; on the system call return, it switches back to the > user stack. That allows you to protect the stack from any user access > while in kernelmode and would prohibit this kind of thing. >
Since all arch need save the function return address into stack eventually, if userspace pass a pointer inside the stack and request kernel read the file provided by userspace to this pointer, then kernel may get the wrong return address and run the malicious code with the highest privilege. The keypoint isn't whether we use two(user/kernel) stack or single stack, but the kernel may corrupt the return address saved in the stack and then jump to the attacked code before low the privilege. > > > >>> my question was if these kinds of checks were for some reasons considered > >>> unnecessary for nuttx. > >> At this point, there were never considered at all. Whenever I find > >> security issues in PROTECTED builds, I add that to the TODO list (if I > >> don't fix them). > >> > > I think that most syscall which contain pointer has the security issue > > in PROTECTED/KERNEL mode. > > Certainly if high security is need, they all should be reviewed. Linux > goes to a lot of trouble to access data pointed to by user-provided > pointers. We might need to add all of those access macros in the future. > For Linux, most security bug is found inside drivers not core part. > KERNEL mode is a little more complex in that you also have to assure > that the correct MMU mappings are in place before to access user data > from a different kernel thread (like a work queue). > As my explanation before, even the same thread also has the bug I described. Acttually, what I describe is a very basic exploition. > Greg > >
