30
Aug
I believe this is one of the most stable release so far 🙂
The full announcement can be found here:
http://www.openwall.com/lists/announce/2018/08/30/1
I’m already working on the next version of LKRG which will include (among others) *_JUMP_LABEL support for modules as well (for now LKRG supports it just for kernel core .text). This is a big, complicate and heavy change and that’s why we decided to announce 0.4 now since we wanted to have a stable release.
Thanks,
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
27
Mar
LKRG 0.2 was just released and the announcement note can be found here:
http://openwall.com/lists/announce/2018/03/27/1
9
Feb
LKRG 0.1 was just released:
The change log is as follows:
Read more
30
Jan
I’m happy to announce that my moonlight project is finally released. Thanks to Alexander Peslyak (a.k.a. Solar Designer) it is available through Openwall.
Linux Kernel Runtime Guard (LKRG) is a loadable kernel module that performs runtime integrity checking of the Linux kernel and detection of security vulnerability exploits against the kernel. As controversial as this concept is, LKRG attempts to post-detect and hopefully promptly respond to unauthorized modifications to the running Linux kernel (integrity checking) or to credentials (such as user IDs) of the running processes (exploit detection). For process credentials, LKRG attempts to detect the exploit and take action before the kernel would grant the process access (such as open a file) based on the unauthorized credentials. You can download the current experimental version of LKRG at its brand new homepage:
LKRG has been in (re-)development for a couple of years, and builds upon one of my prior’s experience with a related project in 2011 (for CERN).
Official announcement had been made by Openwall and it can be read here:
http://www.openwall.com/lists/announce/2018/01/29/1
A lot of useful technical information about LKRG can be found on Openwall wiki page:
http://openwall.info/wiki/p_lkrg/Main
If you would like to support LKRG, you are very welcome to do so 😉 It can be done via Patreon website here:
https://www.patreon.com/p_lkrg
Best regards,
Adam ‘pi3’ Zabrocki
18
Apr
During Microsoft Patch Tuesday on April (2017) some of the Hyper-V vulnerabilities (found be me) were fixed:
Remote Code Execution – CVE-2017-0181 (details)
Denial of Service – CVE-2017-0182 (details)
Denial of Service – CVE-2017-0186 (details)
23
Sep
Linux kernel programming is always a challenge. Especially, when you are playing with very low-level functionality (like manually sending IPI between the CPUs/cores). Unfortunately, this specific functionality kept making troubles for me for a couple of weeks and I haven’t found ANY information on the internet regarding the issue which I hit/met. That’s why I decided it could be useful for other people if I describe my journey with the APIs like smp_call_function_single() / on_each_cpu(), NMI watchdog which can kill correct task and do not inform about problematic CPU/core etc. I’ve been discussing this issue with Alexander (Solar Designer) and he has started a discussion about that on Linux Kernel Mailing List (LKML) which you can find here:
http://lkml.iu.edu/hypermail/linux/kernel/1609.2/03265.html
Thanks,
Adam
Hi,
The journey into CVE-2014-9322 is not straightforward but it is worth to spend some time on it and analyze all available information. I will try my best…
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