I am proud to share that I was elected the Vice Chair of the RISC-V J-extension (so-called J-ext) Task Group 🙂 My last 3-4 years of work on the RISC-V architecture were quite fruitful:
- I am an author of RISC-V Pointer Masking extension:
https://github.com/riscv/riscv-j-extension/blob/master/zjpm-spec.pdf - I am one of the Contributors to RISC-V Control Flow Integrity (CFI):
https://github.com/riscv/riscv-cfi/blob/main/riscv-cfi.pdf - I help driving I/D consistency extension
- HWASAN and Memory Tagging (MTE) on RISC-V
- I found a critical bug in the RISC-V architecture (not in the implementation of a specific processor) that got CVE-2021-1104. Among other things, I talked about this vulnerability in 2021 at the DefCon 29 conference
Thanks,
Adam
16
Jun
Blind TCP/IP hijacking is still alive! After 13 years, Windows 7/XP/2K/9x (and not only) full blind TCP/IP hijacking bug finally got an allocated CVE-2023-34367 (thanks to MITRE). Interestingly, The Pwnie Awards nomination for this research and the published write-up + PoC didn’t help to get it sooner 😉
Read more17
May
At first, I didn’t plan to write an article about the problems with bug bounty programs. This was supposed to be a standard technical blogpost describing an interesting bug in the Linux Kernel i915 driver allowing for a linear Out-Of-Bound read and write access (CVE-2023-28410). Moreover, I’m not even into bug bounty programs, mostly because I don’t need to, since I consider myself lucky enough to have a satisfying, stable and well-paid job. That being said, in my spare time, apart from developing and maintaining the Linux Kernel Runtime Guard (LKRG) project, I still like doing vulnerability research and exploit development not only for my employer, and from time to time it’s good to update your resume with new CVE numbers. Before I started to have a stable income, bug bounties didn’t exist and most of the quality vulnerability research outcome was paying the bills via brokers (let’s leave aside the moral questions arising from this). However, nowadays we have bug bounty programs…
Read moreIntroduction
During the last Patch Tuesday (13th of October 2020), Microsoft fixed a very interesting (and sexy) vulnerability: CVE-2020-16898 – Windows TCP/IP Remote Code Execution Vulnerability (link). Microsoft’s description of the vulnerability:
“A remote code execution vulnerability exists when the Windows TCP/IP stack improperly handles ICMPv6 Router Advertisement packets. An attacker who successfully exploited this vulnerability could gain the ability to execute code on the target server or client.
To exploit this vulnerability, an attacker would have to send specially crafted ICMPv6 Router Advertisement packets to a remote Windows computer.
The update addresses the vulnerability by correcting how the Windows TCP/IP stack handles ICMPv6 Router Advertisement packets.”
This vulnerability is so important that I’ve decided to write a Proof-of-Concept for it. During my work there weren’t any public exploits for it. I’ve spent a significant amount of time analyzing all the necessary caveats needed for triggering the bug. Even now, available information doesn’t provide sufficient details for triggering the bug. That’s why I’ve decided to summarize my experience. First, short summary:
- This bug can ONLY be exploited when source address is link-local IPv6. This requirement is limiting the potential targets!
- The entire payload must be a valid IPv6 packet. If you screw-up headers too much, your packet will be rejected before triggering the bug
- During the process of validating the size of the packet, all defined “length” in Optional headers must match the packet size
- This vulnerability allows to smuggle an extra “header”. This header is not validated and includes “Length” field. After triggering the bug, this field will be inspected against the packet size anyway.
- Windows NDIS API, which can trigger the bug, has a very annoying optimization (from the exploitation perspective). To be able to bypass it, you need to use fragmentation! Otherwise, you can trigger the bug, but it won’t result in memory corruption!
25
Jun
Hi,
We’ve just announced a new version of LKRG 0.8! It includes enormous amount of changes – in fact, so much that we’re not trying to document all of the changes this time (although they can be seen from the git commits), but rather focus on high-level aspects. I encourage to read full announcement here:
https://www.openwall.com/lists/announce/2020/06/25/1
Btw. Among others, we have added support for Raspberry Pi 3 & 4, better scalability, performance, and tradeoffs, the notion of profiles, new documentation, @Phoronix benchmarks, and more
Best regards,
Adam
22
Jul
Hi,
We’ve just announced a new version of LKRG 0.7! As I’ve promised, now we have ARM support (AArch64). Additionally, LKRG can now be run under GRSecurity kernels. This release includes a lot of changes and I encourage to read full announcement here:
https://www.openwall.com/lists/announce/2019/07/21/1
Best regards,
Adam
18
Jul
This time I would like to announce sort of a stable release of Linux Kernel Runtime Guard (0.3).
The full announcement can be found here:
http://www.openwall.com/lists/announce/2018/07/04/1
Additionally, I was giving a talk on Confidence 2018 security conference about LKRG’s internals (LKRG under the hood). We’ve just released the slides online here: http://www.openwall.com/presentations/CONFidence2018-LKRG-Under-The-Hood/
Additionally, Confidence talks were recorded and you can find a video from my lecture here:
https://www.youtube.com/watch?v=tOiPM692DOM
Thanks,
Adam
2
Feb
It’s long time I haven’t been posting here. Just quick update, excluding private conferences where I gave a few talks (which I can’t mention), last time I was a speaker on some known conferences:
– Security B-Sides in Warsaw 2014 (as anonymous speaker). I was talking about attacks on modern x86/x64 architecture (like TLB-splitting, virtualization, AMT, etc.). Conference has warm and homely atmosphere which helps to integrate every attendee. This is rare opportunity in modern industrial IT sec world…
– Secure 2014. Each year conference is more and more well-known and famous. CERT Poland (organizer) strives to keep high value of his baby and every year invites most skilled speakers. This year (2014) I had a chance to gave an official talk on behalf of the Microsoft: “The exploitation arm race between attackers and defenders”. I’ve received massive positive feedback which is for me the largest acknowledgements of my work. Conference is very professional and prepared down to the last detail.
From the most modern news:
– I have found a bug in nginx (on Win32 platform) and official patch can be found here:
http://hg.nginx.org/nginx/rev/78271500b8de
http://forum.nginx.org/read.php?29,256289
– One of my friend started interesting project – hack.it. The aim is to show as realistic as possible documentary / reality about IT security industry. Nowadays IT security is a “hot” topic (more than ever) which doesn’t help to promote proper transmission. It’s is not first time when someone is trying that, unfortunately not many projects was successful on this field. I wish him the best and I hope to receive the highest quality of the documentary which can be done, because I know he can do it 😉
Btw. I hope I’ll have more time to be more active here… 🙂
Btw2.
Best regards,
Adam
Introduction.
I was heavily playing with Stack Smashing Protector a few years ago. Some of my research (observation) I decided to publish on phrack magazine but not everything. Two years ago my professional life moved to the Windows environment and unfortunately I didn’t have time to play with UNIX world as much as before. One weekend I decided to reanalyze SSP code again and this write-up is describing a few of my observations I’ve made during the work…
… which can be shortly summarized as:
Not security related…
- We can change program’s name (from SSP perspective) via overwriting memory region where pointer to “argv[0]” points to.
- We can crash Stack Smashing Protector code in many ways:
- Via corrupting memory region pointed by “__environ” variable.
- Via setting “LIBC_FATAL_STDERR_” to the edge of valid addresses.
- Via forcing “alloca()” to fail – e.g. stack exhaustion.
- There is one more bug which I’m analyzing more comprehensively at point 4. It may indirectly force SSP to crash. It exists in DWARF stack (state) machine which is responsible for gathering information about the stack trace (“__backtrace()”) and prints it.
- We can slightly control SSP’s execution flow. (Un)Fortunately it doesn’t have any influence for the main execution (what about security?). Following scenarios are possible:
- Force SSP to open “/dev/tty”
- Force SSP not to open “/dev/tty” and assign to the “fd” descriptor “STDERR_FILENO” value:
#define STDERR_FILENO 2 /* Standard error output. */
- Crash SSP via 2b. scenario
- We can crash indirectly SSP via unwinding algorithm (read-AV or we can be killed by “gcc_unreachable” or “gcc_assert” function) – DWARF stack (state) machine:
- Simulate FDE object was not found
- Simulate FDE object was found.
Somehow security related…
- We can force SSP to allocate a lot of memory and cause Denial of Service via Resource Exhaustion attack.
- Theoretical Information leak:
- Stack cookie information leak.
- Any kind of information leak
- File corruption.
Full write-up is available here 🙂
Best regards,
Adam ‘pi3’ Zabrocki
C++ supports developers in object-orientated programming and removes from the developer the responsibility of dealing with many object-oriented programming (OOP) paradigm problems. But these problems do not magically disappear. Rather it is the compiler that aims to provide a solution to many of the complexities that arise from C++ objects, virtual methods, inheritance etc. At its best the solution is almost transparent for the developers. But beware of assuming or relying on ‘under-the-hood’ behavior. This is what I want to share in this post – some aspects of how compilers deal with C++ objects, virtual methods, inheritance, etc. At the end I want to describe a real-world problem that I analyzed recently, which I called a “pointer casting vulnerability”.
The full write-up you can find on the Microsoft SRD blog here…
Best regards,
Adam