One Article Review
| Source |  GoogleSec |
|---|---|
| Identifiant | 8477255 |
| Date de publication | 2024-03-28 18:16:18 (vue: 2024-04-06 22:07:27) |
| Titre | Adressez désinfectant pour le firmware à métal nu Address Sanitizer for Bare-metal Firmware |
| Texte | Posted by Eugene Rodionov and Ivan Lozano, Android Team With steady improvements to Android userspace and kernel security, we have noticed an increasing interest from security researchers directed towards lower level firmware. This area has traditionally received less scrutiny, but is critical to device security. We have previously discussed how we have been prioritizing firmware security, and how to apply mitigations in a firmware environment to mitigate unknown vulnerabilities. In this post we will show how the Kernel Address Sanitizer (KASan) can be used to proactively discover vulnerabilities earlier in the development lifecycle. Despite the narrow application implied by its name, KASan is applicable to a wide-range of firmware targets. Using KASan enabled builds during testing and/or fuzzing can help catch memory corruption vulnerabilities and stability issues before they land on user devices. We\'ve already used KASan in some firmware targets to proactively find and fix 40+ memory safety bugs and vulnerabilities, including some of critical severity. Along with this blog post we are releasing a small project which demonstrates an implementation of KASan for bare-metal targets leveraging the QEMU system emulator. Readers can refer to this implementation for technical details while following the blog post. Address Sanitizer (ASan) overview Address sanitizer is a compiler-based instrumentation tool used to identify invalid memory access operations during runtime. It is capable of detecting the following classes of temporal and spatial memory safety bugs: out-of-bounds memory access use-after-free double/invalid free use-after-return ASan relies on the compiler to instrument code with dynamic checks for virtual addresses used in load/store operations. A separate runtime library defines the instrumentation hooks for the heap memory and error reporting. For most user-space targets (such as aarch64-linux-android) ASan can be enabled as simply as using the -fsanitize=address compiler option for Clang due to existing support of this target both in the toolchain and in the libclang_rt runtime. However, the situation is rather different for bare-metal code which is frequently built with the none system targets, such as arm-none-eabi. Unlike traditional user-space programs, bare-metal code running inside an embedded system often doesn\'t have a common runtime implementation. As such, LLVM can\'t provide a default runtime for these environments. To provide custom implementations for the necessary runtime routines, the Clang toolchain exposes an interface for address sanitization through the -fsanitize=kernel-address compiler option. The KASan runtime routines implemented in the Linux kernel serve as a great example of how to define a KASan runtime for targets which aren\'t supported by default with -fsanitize=address. We\'ll demonstrate how to use the version of address sanitizer originally built for the kernel on other bare-metal targets. KASan 101 Let\'s take a look at the KASan major building blocks from a high-level perspective (a thorough explanation of how ASan works under-the-hood is provided in this whitepaper). The main idea behind KASan is that every memory access operation, such as load/store instructions and memory copy functions (for example, memm |
| Envoyé | Oui |
| Condensat | 0x00 0x01 0x07 0x40000000 0x42700000 0x4a700000 0x4fffffff 0xf1 0xf2 0xf3 0xfa 0xff 1/8th 101 40+ Chen Dominic Ferz Highness Karimi Khing Mer Nayar Piram Qsun Roomugan Sami Somogai Stefan Stephen Tolwanen aarch64 able aborting/crashing above access accessed accessible accessible/poisoned accessible: accessing accommodating accounted acknowledgements: actionable addition additional additionally address addresses adds adjacent adoption after against aligned all allocated allocation allocator allows along already also alternative always amount and/or android another any applicable application apply applying are area aren argument arm around array asan assembly assume assumption avoid avoiding back bare base based been before behind benefit between bloating blocks blog both bounds buffer buffers bugs bugs: building builds built bulk but by: byte bytes c/c++ call called caller calls can capable capturing case cases catch catching cause check checks clang classes cleanup code colleagues common compiler compiler: comprehensive conclusion constructors/destructors context contribute contributions copy corresponding corresponds corruption could cover covered covering covers critical custom data deallocated deallocation dedicated default define defined defines demonstrate demonstrates denotes depends dereferencing describes despite destination/source destructors details detect detecting detects developed development device devices different directed discover discovery discussed does doesn don double/invalid dram due during dynamic eabi each earlier early easily edge efforts: element embedded emulator enable enabled enabling encode encodes encourage end ensure entire environment environments epilogue/prologue equal error essentially eugene even every evgenii example exception existing explanation explicitly explore exploring exposes extensively extra fails false finally find firmware first fix fixed focus following formula: found free freed freeing frequently from fsanitize=address fsanitize=kernel function functions further fuzzers fuzzing generate generated generating given global globals globals=1 goes great handle handling happens has have header heap help here high highly hood hook hooks how however idea ideally identify immediately implement implementation implementations implemented implications implied improvements including increase increasing indicate individual infer inline input insert inserts inside instance instead instruct instructions instructs instrument instrumentation instrumented instrumenting instruments intended interest interface introducing invalid invoked issues its ivan jover just kasan keep kernel land languages latest led left less let level leveraging libclang library lifecycle like likelihood likely linker linux linux/mm/kasan/kasan list llvm load load/store loadxx local located logging longer longjmp look lower lozano main maintained major majority managed management many mapping maps mark may means memcpy memmove memory memset mentioning metal mid might mitigate mitigations mllvm most multiple must name narrow necessary need needed noabort none noreturn normal normally not noticed object offset offset=0x42700000 often once one ones only operation operations optimize option optional options order originally other others otherwise out outline overview own padding particular pass perform performance performs period perspective piqueras place placing platform please pointer poison poison/unpoison poisoned positives post posted power pre predefined prevent previously prioritizing proactively probability problem processing produced production programs project provide provided provides qemu quarantine questions range rather reach readers reading reads/writes ready received red refer reference region regions regions: register releasing relies remediated removed removes report reporting reports required requires researchers reserve respectively responsibility result resulting return returning reveal revealed right rodionov roger routine routines running runtime runtimes rust safe safety sanitization sanitized |
| Tags | Tool Vulnerability Mobile Technical |
| 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.