27

Mar

by pi3

LKRG 0.2 was just released and the announcement note can be found here:

http://openwall.com/lists/announce/2018/03/27/1

Read more

9

Feb

by pi3

LKRG 0.1 was just released:

http://www.openwall.com/lkrg/

The change log is as follows:
Read more

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:

http://www.openwall.com/lkrg/

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

by pi3

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

by pi3

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…

Read more

2

Feb

by pi3

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. Ponieważ obiecałem znajomemu, że napiszę jakiś post z dedykacją dla niego, dedykuję ten wpis dla Mateusza “shm” Kocielskiego 🙂

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…

  1. We can change program’s name (from SSP perspective) via overwriting memory region where pointer to “argv[0]” points to.
  2. We can crash Stack Smashing Protector code in many ways:
    1. Via corrupting memory region pointed by “__environ” variable.
    2. Via setting “LIBC_FATAL_STDERR_” to the edge of valid addresses.
    3. Via forcing “alloca()” to fail – e.g. stack exhaustion.
    4. 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.
  3. 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:
    1. Force SSP to open “/dev/tty”
    2. Force SSP not to open “/dev/tty” and assign to the “fd” descriptor “STDERR_FILENO” value:

    #define STDERR_FILENO 2 /* Standard error output. */

    1. Crash SSP via 2b. scenario
  1. 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:
    1. Simulate FDE object was not found
    2. Simulate FDE object was found.

Somehow security related…

  1. We can force SSP to allocate a lot of memory and cause Denial of Service via Resource Exhaustion attack.
  2. Theoretical Information leak:
    1. Stack cookie information leak.
    2. Any kind of information leak
    3. 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

I had a pleasure to give a talk at the Confidence 2013 conference. This year conference was in Krakow (28-29th of May). The first CONFidence conference was organized in 2005 and from the beginning became one of the biggest security event in the Europe. Each year many speakers from all around the world attend to the conference. As you can realize schedule of the conference usually keeps high technical standards.

This year I was talking about Crashdumps. Crashdumps are often underestimated source of very interesting information. It is a common belief that they are used only for application/system bugs/vulnerabilities analysis. In this presentation I would like to show a little bit different approach for this source of information. Microsoft Windows allows to change default configuration for WER/CER protocol in such a way, that all generated crashdumps will be stored in a custom storage. This is very useful in a large corporate networks, where we can find tens, hundreds or even thousands of machines, because more than a hundred crashdumps may be generated per day. In most of the cases administrators are afraid of a critical information leak (XBI, PII) via crashdumps, but could they gain some useful knowledge about the network status via this source? I was trying to show what kind of benefits could be gained if we start analyzing crashdumps independently and in a little bit different perspective…

 

Official topic of my talk was: “Crashdumps: hunt 0days and rootkit”. Now you are able to see it online:
http://www.youtube.com/watch?v=VdHiUK3q_3A

In fact it wasn’t my first talk on this conference. In 2007 I gave a talk about shellcodes on MIPS architecture 😉

 

Some of you may realize that conferences are not only about the presentations! In fact for me the most valuable is possibility to meet old friends and get new one 😉 Especially from the IT sec world… This year I was able to meet my old team from Hispasec 😉 Polish Hispasec division had 4 employees:

– Gynvael Coldwind

– Mateusz ‘j00ru’ Jurczyk

– Marcin ‘icewall’ Noga

– … and me – Adam ‘pi3’ Zabrocki 😉

Because each of us continues their career in own way, it’s very difficult (and rare) to meet together again. CONFidence gave us opportunity for that and this resulted on the following photo (click to enlarge):

 

From the left: j00ru, pi3, Gynvael Coldwind, Icewall…

There is space for next photos 😉

 

Best regards,

Adam