One Article Review
| Source |  ProjectZero |
|---|---|
| Identifiant | 8302606 |
| Date de publication | 2023-01-19 09:33:48 (vue: 2023-01-19 18:06:34) |
| Titre | Exploiting null-dereferences in the Linux kernel |
| Texte | Posted by Seth Jenkins, Project Zero For a fair amount of time, null-deref bugs were a highly exploitable kernel bug class. Back when the kernel was able to access userland memory without restriction, and userland programs were still able to map the zero page, there were many easy techniques for exploiting null-deref bugs. However with the introduction of modern exploit mitigations such as SMEP and SMAP, as well as mmap_min_addr preventing unprivileged programs from mmap’ing low addresses, null-deref bugs are generally not considered a security issue in modern kernel versions. This blog post provides an exploit technique demonstrating that treating these bugs as universally innocuous often leads to faulty evaluations of their relevance to security. Kernel oops overview At present, when the Linux kernel triggers a null-deref from within a process context, it generates an oops, which is distinct from a kernel panic. A panic occurs when the kernel determines that there is no safe way to continue execution, and that therefore all execution must cease. However, the kernel does not stop all execution during an oops - instead the kernel tries to recover as best as it can and continue execution. In the case of a task, that involves throwing out the existing kernel stack and going directly to make_task_dead which calls do_exit. The kernel will also publish in dmesg a “crash” log and kernel backtrace depicting what state the kernel was in when the oops occurred. This may seem like an odd choice to make when memory corruption has clearly occurred - however the intention is to allow kernel bugs to more easily be detectable and loggable under the philosophy that a working system is much easier to debug than a dead one. The unfortunate side effect of the oops recovery path is that the kernel is not able to perform any associated cleanup that it would normally perform on a typical syscall error recovery path. This means that any locks that were locked at the moment of the oops stay locked, any refcounts remain taken, any memory otherwise temporarily allocated remains allocated, etc. However, the process that generated the oops, its associated kernel stack, task struct and derivative members etc. can and often will be freed, meaning that depending on the precise circumstances of the oops, it’s possible that no memory is actually leaked. This becomes particularly important in regards to exploitation later. Reference count mismanagement overview Refcount mismanagement is a fairly well-known and exploitable issue. In the case where software improperly |
| Envoyé | Oui |
| Condensat | &mm &mmlist &mss &wait “mm: &mss &wait //mm 0 believes ctx in null on priv sizeof table true void *v ’s *ctx *mm *mm; *priv *table *vma; /proc/ /proc/self/smaps /smaps 2022 232 kernel 232 times 64591e8605 ; //mmap ; //task ; //the = = 0; = 0; i = get = m = mmap = null; = priv = rcu = vma >binfmt >inode >ioctx >mm >mm; //with >mmap >mmap; vma; vma >mmlist >module >nr >nr; ++i >private; >table >task >vm able about above abrupt halt access across actually additionally addr preventing address addresses advantage after again aio aio allows aio contexts aio is aio itself aio on aio path aio’s internal aioksm all allocated allocates allocation allow already also although amount another any are area associated atomic attacker attempts avoid away back backport backtrace balance because becomes been before beginning behavior behaviors being beneficial best between bit blog both box bprocess bug bug indicating buggy bugs but by multiple byte b|c c’s call called callee callees calls can can’t candidate cannot carefully case cause caused causes causing cease children choice circumstances class classic cleanup clear clearly clone clone flag clones close code coincidentally comp complete completed completion concept conclusion concurrent condition condition: conditions consequently consequently induce a considered console context continue continue; contract corresponding corruption count couple cprocess create created creating ctx currently days dead dead which deadlock deadlocked deadlocks debug decrement decrementing decrements del demonstrative depending depicting deref dereference dereferences derivative descriptor despite destroy detectable determines didn’t die difficult directly discovered distinct distributed dmesg does doesn’t doesn’t decrement a don’t done double down during d|e each easier easily easy effect effects effort empty end end; ends enough ensure enter entire equal error esrch; etc evaluate evaluations even events every example example exe execution existing exit exitkhugepaged exits expensive exploit exploitable exploitation exploiting extends fair fairly faulty fdget took fetched file file file has file itself file mutex file within final first fix fixed fledged following follows:process for forever forks free freed freeing frees from full function functions:uprobe future gather gen generally generate generated generates generating given goes going good goto out graphical grow guarantees half hang happen has have having header held here highly hit hold holding how however huge idea if important important that improperly improve increment incremented incrementing indefinite inherit init innocuous inside instead int i int ret intended intention interface introduction involve involves ioctx ioctx is ioctx to irregular irrelevant isn’t issue issue in issues it’s its itself jenkins just kali kernel kernels kfree khugepaged kill killable known ksm last later lead leads leak leaked leaked/incremented leakedthe leaking least leaves less let’s like limit limit which linux list little local lock lock does lock in lock is locked locking locks log loggable logging longer look loop low lru lts make makes manifest many many times map mapped maps may mean meaning means members memory mempolicy memset min mismanagement mitigations mm mm and mm from mm is mm struct can mm through mm will mm’s mmap mm: mm; mmap mmap member mmap unconditionally mmap” mmap’ing mmdrop mmget mmget and mmget being mmget/mmput on mmget/mmput’s on mmput mmput mmput on |
| Tags | Guideline |
| Stories | |
| Notes | ★★★★ |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.