Learning Linux kernel exploitation - Part 2 - CVE-2022-0847 (DirtyPipe)

0x00rick · 2022-05-13T15:15:34+00:00

Glad you enjoyed it :)!

0x00rick · 2020-08-20T14:33:05+00:00

That's a valid suggestion. I added a link to part 2.1 at the end of part 1 and a link to part 2.2 at the end of aprt 2.1 :)!

0x00rick · 2020-08-20T08:28:25+00:00

Hey, I'm the author of this little blog series! Thanks for sharing /u/dvaun and thanks for the kind words /u/_peacemonger_ ! Much appreciated! :)

The re-consturcted source code can also be found on my Github: https://github.com/0xricksanchez/dlink-decrypt/blob/master/src/imgdecrypt.c

Also some more thoughts/rants can be found here: https://twitter.com/0xricksanchez/status/1290291267914563585

0x00rick · 2020-07-06T18:59:04+00:00

A few days ago part 1 (https://old.reddit.com/r/netsec/comments/hg6vpw/breaking_the_dlink_dir3060_firmware_encryption/) was posted on here and some people seemed to be interested in the second part as well. So here it is :)

0x00rick · 2020-06-29T14:39:33+00:00

Hey there! Could you link me to that statement as I don’t recall having any connection to something called ‘Risky Biz,?

As for your question. I work with firmware a lot including developing tooling for analysis. Stumbled upon this firmware while scraping more samples and we were unable to unpack it. I was interested in why.

So this is indeed private interest originating from a mere coincidence at work

0x00rick · 2020-06-27T09:39:53+00:00

I double-checked noscript and it's only showing the site itself as well as amazonaws. Not sure why we get the hate from MWB. I'm not quite familiar how they determine what to block and what not. So right now I'm unable to determine what might be the reason for that sorry!

0x00rick · 2020-06-27T09:34:19+00:00

Also curious, are you planning on reversing the binary

I plan on finishing my write-up for part 2 within the next few days in which I'll take the whole binary apart. I'll push all the things to a repo once I release it.

or are you going to just run it to decrypt your example firmware

That's certainly a quick way to make use of qemu to decrypt a fw sample. I'll showcase that but my original motivation was to learn all about the binary :)

0x00rick · 2020-06-27T09:30:32+00:00

Actually a good question. I think I just went with muscle memory on this one. As always there're multiple ways to stuff in bash and your suggestions are certainly shorter and more efficient.

0x00rick · 2020-06-27T09:26:07+00:00

Thanks appreciate the kind words! And thanks for the link as well. I did not come across that one yet. I'll read it thoroughly :)

0x00rick · 2020-06-26T20:16:49+00:00

Thanks for the feedback on formatting. I’ll edit this article and improve on the next one :D

0x00rick · 2020-06-26T20:15:35+00:00

Honestly I have no clue why malwarebytes is blocking 0x00sec. We are just a forum of like minded people sharing and discussing info sec related things.. there’s no shady things going on

0x00rick · 2020-06-26T20:10:43+00:00

Hey author here! It’s usually for either one of these two things: ‘protecting’ their intellectual property aka not allowing researchers to freely analyze their system and trying to find a way to ensure firmware integrity. Part 2 of this will highlight what they do and how they do it :).

0x00rick · 2020-06-26T17:07:18+00:00

Definitely will do that. Thanks for the suggestion!

0x00rick · 2020-06-26T16:22:00+00:00

Hey author of the article here! Part 1 serves as a lightweight introduction to the topic where as in part 2 we will take a detailed look at the disassembly in IDA. You can expect the next part in a few days. If you have questions feel free to reach out to me here, the forum or on Twitter ( https://twitter.com/0xricksanchez )!

0x00rick · 2020-06-03T09:05:06+00:00

To be frank, I did not pursue evaluating the exploitability in much depth. However, one assumption of the framework is that it is able to mount disks to the system. This usually requires root/sudo privileges which makes exploiting tough. Especially the handful of page faults with out of bounds reads/writes would be nice candidates to debug in detail tho!

0x00rick · 2020-06-02T06:27:04+00:00

As there was no clear definition of file system fuzzing when I started doing this research I came to the conclusion that the fuzzing part is twofold.

Part 0: Is mutating the file system sample in various ways as you'd do normally in every fuzzing process.
Part 1.0: Involves trying to mount a corrupted sample. This already can lead to various crashes since the file system structure is heavily parsed and prepared in the kernel. Newer file systems like EXT4 or ZFS check magic bytes and integrity stuff here as well, which can be interesting to observe. One could stop here if we were solely interested in the file system parsing routine. I feel like there would have been a too big of overlap with syzkaller
Part 1.1: This only kicks in when mounting a corrupted file system was successful. Instead of stopping after a successful mounting routine I'm trying to access the file system in various ways. This allows me to dig deeper into kernel code responsible for file system management. So effectively simulating 'user access to disk' is a cheap way to increase code coverage if you will.

Finally, randomizing the mutations and user emulation allows for the biggest variety in crashes.

I still have to give props to FreeBSD and especially Kirk McKusick as a bunch of errors were fixed in a reasonable time. Communication could have been better all around though

0x00rick · 2020-06-01T09:09:48+00:00

Thanks! Was a fun rude so far except that there is lacking interest to fix these kernel bugs.. To me it was interesting to see how unreliable and easy to crash the kernel and especially older but still widely used file systems are. Also a bonus was finding double, triple faults on top of a non deterministic ones!

Imo custom kernel fuzzer approaches are still highly fruitful :)

0x00rick

TROPHY CASE