Wednesday, August 5, 2020

SVE-2019-15230: A bug collision

Researchers from Team T5 recently published their write-up on exploiting a bug in S-Boot and obtaining code execution in the Samsung Secure Bootloader (S-Boot).
This week, they're going to present it at the BlackHat 2020 conference.
Their write-up contains a lot of technical details and I recommend you to read it.

In their report, they say "Another security research team found this vulnerability at the same time and report it to Samsung. ID: SVE-2019-15230".
This one-man security research team was me.
As I described in the previous two posts, in 2019 I got myself a Samsung Galaxy S10 phone with an Exynos SoC and decided to hunt for security bugs.
After finding the first issue (which is also my first SVE and my first report rated "Critical"), "SVE-2019-14371", I decided to carefully review the code around the location where I found the first bug.

I found an integer overflow which could potentially lead to memory corruption, overriding the entirety of S-Boot code and data.


Funnily enough, I got the SVE even though I have not submitted the POC which achieves code execution (well, to be fair, I reported it almost two months earlier).
I have submitted the one which demonstrates that the device handles non-underflowed values correctly whereas a "huge" buffer size causes it to freeze.
I came to the conclusion it's hard to exploit because I could not find a device with the good memory layout.



I have downloaded a ton of images: for S10, S9, S7, A50, J series phones.
Team T5's trick was to find a condition where the error handler code will make the memory layout good.
I have unfortunately overlooked that in S8 the download buffer is right before the S-Boot code AND it was not using the newer ("compressed" or "smp") download modes.
Since I never realized how to make that S-Boot falls back to the "legacy" buffer at 0xc0000000, I was focusing on the first underflow here, and came to the conclusion that there's not much I could do about it.

I wrote in my report to Samsung that USB transfer is done with DMA and I have not seen S-Boot initialize SMMU so it's surely exploitable.
If we could make the buffer point before S-Boot, of course (which I have not found out how to do).
I like how Team T5 discusses that normally it would be hard to exploit the bug as most code and data could be cached, but as they found a bunch of pointers in an uncached area, overwriting them works, even if it's done by the USB controller (which is not necessarily cache-coherent) and the CPU is unaware.

Although it was already the third Critical issue I found in S-Boot by that time and I was completely burnt out on trying to develop yet another POC.

Is the security of Samsung phones bad? NO.

I think, it's quite on par with the competitors. While the Android Security Updates page (https://security.samsungmobile.com/securityUpdate.smsb) regularly lists "High" and "Critical" issues, very few of them happen in the S-Boot bootloader (which is one of the earliest pieces of code which execute on the device). What it means is that the attacker need to first unlock the phone. So keeping your phone locked and BT/WLAN off should give a reasonable level of protection in the settings when you can't keep an eye on your phone.

There are of course things that could be improved, like adding some mitigations to the bootloader (stack cookies, heap guard pages). However, in this case this would not help at all, because the memory copy (and thus overwriting code/data) is not done by the S-Boot code, but by the USB DMA controller.

Bootloaders almost never implement ASLR, and even kernels which do only implement it for the virtual memory, the physical address remains constant or predictable. In fact, as it's overwriting uncached code (exception handlers), it could even work if the CPU supported ARM MTE. So this is in some sense the mother of all S-boot bugs.

In some aspect, the root cause here is very similar to the IROM bug found by Frederic Basse: an integer overflow and copying data from USB, although in case of IROM it seems that IROM's code is copying USB data by small chunks.

Of course it would not be fair to judge the design decisions now that we know about these bugs. It would be nice to add some checks to ensure DMA regions don't intersect with code/data. Enabling SysMMU would not hurt. This is becoming somewhat worrisome now that USB4 has been announced with Thunderbolt-like DMA capabilities. It's unfortunate that most bootloaders do not focus on this.

Now, the problem is that adding mitigations is quite hard as well as reasoning about their effectiveness. Without memory safety you can never be sure that the code is not exploitable. And as we've just seen before, it's unlikely that even a hardware safety oriented at memory safety are likely to be bypassed. Maybe a combination of MTE/KASAN and instrumenting all DMA memory management would work, but again it relies on the individual developers thinking of all corner cases. At some point bootloaders/firmwares could become as complex as the Linux kernel itself.
To this end, an interesting approach is moving firmware update, including USB download, to user-space and indeed running it from Linux, as Google started doing recently.

Why are the bugs present then?

It often happens that bugs appear in two areas: the just-written code with new functionality (which not so many people had a chance to review) or the old code (people got tired of trying to find bugs there and gave up).

I think we can draw two conclusions from this.
  • As a vendor, one should not assume that security or code review is a one-off effort and they need to re-review their stuff once in a while, especially bringing in the perspective of new team members.
  • As the user, if you expect maximum security, perhaps don't switch to the new tech immediately, give it 2-3 months for the most obvious and annoying issues (not only security bugs) to get ironed out.

What can I do to protect myself?

Enable the "Find My Mobile" feature of your Samsung phone.

Before I and TeamT5 reported a few issues to Samsung, S-Boot implemented one mechanism of preventing the phone from being tampered with: when MDM (device administration by a workspace or school) is enabled, certain partitions were not allowed to be flashed.
This, unfortunately, did not protect the user in two scenarios: when they were not using MDM (which is the majoriy of users) or when the vulnerability is in the USB stack before the flashing code (in which case even enabling MDM would buy you nothing).
In mid-2019, Samsung changed the "Find My Mobile" in such way that it would disallow any USB operations (such as ODIN mode) when the device is not unlocked and FMM is enabled.
This should provide a reasonable level of protection for most users.
It is now much harder for an attacker to hack your phone in a few seconds when you're not looking at it (such as at a conference or in the hotel room). Of course, if is still possible to re-program the storage chip by desoldering it, which could expose other potential vulnerabilities, but it's hard to do it quickly and without tamper evidence.

Will you blog about other findings?

Not sure. It's a tricky question.
In general, Samsung is asking to not disclose the issues, at least until the patching and reward process is done, which is understandable. I am grateful that Samsung allowed me to participate in their security reporting program, even though I work for another mobile SoC company, so I'm not particularly interested in making this relationship go sour.

I do, however, see the immense value in describing the bug contents, because personally for me write-ups on Phrack or later Google Project Zero have been useful for understanding how attackers think, which came handy when both writing code and later working as a security engineer.

I guess vendors can have their own reasons to not like when bugs are disclosed. Before working as a security engineer myself, I thought negative PR/news was the major reason. Turns out, it's impossible to predict this factor, and often the minor bugs are over-hyped but serious ones go unnoticed. So maybe this factor is not that important after all.

Another thing I've noticed is that there is a significant interest in some hacking and "mobile repair" forums in bugs even for older firmware revisions, which means there are regions where people rarely update (expensive internet) or... a source of phones which for some reason remain unused and therefore not updated for a while.

Given that mobile phones are supported (security updates and carrier contracts), maybe half of this term (1.5-2 years from the time the bug is patched) is a reasonable delay for holding off disclosure.

8 comments:

  1. "Hi, your blog is really wonderful and awesome. You’re a very skilled blogger. Thanks for sharing such a helpful post. It is extremely helpful for me
    if you want to know about gadget then you can check my site emela
    "

    ReplyDelete
  2. I was diagnosed with ALS (Lou Gehrig's Disease) when I was 46 years old 2 years ago. The Rilutek (riluzole) did very little to help. The medical team did even less. My decline was rapid and devastating. my arms weakened first, then my hands and legs. Last year, a family friend told me about DOCTOR JAMES Herbal mix medicine and his effectiveness in treating l ALS , I contacted him. and ordered for his herbal mix medicine, i was happy to report the treatment effectively treated and reversed my Amyotrophic Lateral Sclerosis (ALS), most of the symptoms stopped, i was able to walk and eat well, sleep well and exercise regularly., i'm pretty active now and my attitude is extremely positive.i joyfully recommend you to DR.JAMES because health is wealth this is a very bad experience with those living with ALS or any other diseases like Shingle,schizophrenia,Bipolar,Stroke, Parkinson's disease,Schizophrenia,Cancer,Scoliosis,Bladder Cancer,Colorectal Cancer,Breast Cancer,Kidney Cancer,Leukemia,Lung Cancer,Skin Cancer,Uterine Cancer,Prostate Cancer,Fibromyalgia,a
    Syndrome Fibrodysplasia ,Epilepsy Dupuytren's disease, Diabetes ,Coeliac disease, Angiopathy, Ataxia,Arthritis,Amyotrophic Lateral Sclerosis,Alzheimer's disease,Adrenocortical carcinoma.Asthma,Allergic diseases.Hiv_ Aids,Herpes,Inflammatory bowel disease ,Copd,Diabetes please do not hesitate to contact him on his Email Drjamesherbalmix@gmail.com

    ReplyDelete
  3. Everything changes in the schengen and many people ignore this new procedure. I was illegal a few months ago and today i got a new identity a new driver's license new passport through: Click Here WhatsApp: +43 677 63703423 I share my experience

    ReplyDelete
  4. Good day! Would you mind if I share your blog with my zynga
    group? There’s a lot of people that I think would really enjoy your content.
    Please let me know. Thanks4K YouTube To MP3
    Express VPN
    HD tune pro
    utorrent pro
    Adguard premium

    ReplyDelete
  5. I like the helpful information you provide in your article….thanks for share.
    Movavi Video Converter

    IDM

    AVG Driver Updater

    Macbooster

    ReplyDelete
  6. What’s Going down i am new to this, I stumbled upon this I’ve found It absolutely useful and it has helped
    me out loads. I’m hoping to give a contribution & assist other users
    like its aided me. Great job.

    microsoft office 2007 keys
    IDM
    Easeus Data Recovery
    Windows 7 activator
    4k video downloader
    Microsoft office 365
    Windows 10 activator
    xforce keygen

    ReplyDelete