PCR get data from bitleaker driver fail?

[mahmouddawod-it]

Hi Napper working and get pcr vulnerable Why in bitleaker fail. And how change drive like /dev/sda3 To /dev/sda5 Sda3 is no lock Sda5 have bitlock

[kkamagui]

Hello @mahmouddawod-it ,

It's a weird situation. Would you tell me about your testing process? Did you fail to start BitLeaker alone?

Best regards,

Seunghun

[roboknight]

I think I actually figured out what the problem was. I traced the values in the TPM registers only to discover that, even though my device was "sleeping", it was really only shutting down the screen. So the TPM wasn't getting a chance to reset. I also realized, after tracing things a bit more, that the TPM was changed from the beginning. So I couldn't figure out a way to get to the values of the TPM right off. I believe that the system may still work, but I have to work on actually getting it to go to sleep correctly. So your code is working beautifully, as far as I can tell, but the system I'm attempting to target, though the TPM may be vulnerable (I checked the model and I think its a pretty common one that is vulnerable), it isn't DIRECTLY because Linux can't make the device sleep correctly. So I'm having to rebuild a version of Linux that might work with it. Additionally, I want it to work from a thumbdrive, which has made things a little more tricky, since I have to use a signed bootloader (like Ubuntu's or Redhat's)... I figured out how to fix some of that, and I believe it will still work because it is only using PCR 7 and 11 (not the fully protected set of registers). But I just have to get the registers to reset by getting Linux to put the device to sleep correctly.

On Wed, Apr 1, 2020 at 16:32, Seunghun Han notifications@github.com wrote:

Hello @mahmouddawod-it https://github.com/mahmouddawod-it ,

It's a weird situation. Would you tell me about your testing process? Did you fail to start BitLeaker alone?

Best regards,

Seunghun

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kkamagui/bitleaker/issues/4#issuecomment-607540023, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABQ75544FTQ2XQEYTBTSRTRKPFIFANCNFSM4LVQVQ4A.

[dell224]

Hi robotknight,

I'm faced with the same issue as you. Did you manage to find a workaround for this?

Thank you.

I think I actually figured out what the problem was. I traced the values in the TPM registers only to discover that, even though my device was "sleeping", it was really only shutting down the screen. So the TPM wasn't getting a chance to reset. I also realized, after tracing things a bit more, that the TPM was changed from the beginning. So I couldn't figure out a way to get to the values of the TPM right off. I believe that the system may still work, but I have to work on actually getting it to go to sleep correctly. So your code is working beautifully, as far as I can tell, but the system I'm attempting to target, though the TPM may be vulnerable (I checked the model and I think its a pretty common one that is vulnerable), it isn't DIRECTLY because Linux can't make the device sleep correctly. So I'm having to rebuild a version of Linux that might work with it. Additionally, I want it to work from a thumbdrive, which has made things a little more tricky, since I have to use a signed bootloader (like Ubuntu's or Redhat's)... I figured out how to fix some of that, and I believe it will still work because it is only using PCR 7 and 11 (not the fully protected set of registers). But I just have to get the registers to reset by getting Linux to put the device to sleep correctly. … On Wed, Apr 1, 2020 at 16:32, Seunghun Han @.***> wrote: Hello @mahmouddawod-it https://github.com/mahmouddawod-it , It's a weird situation. Would you tell me about your testing process? Did you fail to start BitLeaker alone? Best regards, Seunghun — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABQ75544FTQ2XQEYTBTSRTRKPFIFANCNFSM4LVQVQ4A.

[roboknight]

So ultimately I figured out that the device I was trying to deal with, a Microsoft Surface device, unfortunately for some reason, doesn't really HAVE a sleep state S3. So ultimately, since this is pretty much what Bitleaker depends on, it could never really achieve this sleep state in the device I targeted. I did "get it to work" in the sense that I believe I got things RUNNING, but it never produced good results because, as I said, I ultimately couldn't get to sleep state S3. So, even though I believe the hardware to ultimately be vulnerable to Bitleaker, they dodged the bullet by eliminating sleep state S3. I believe, at least in the particular Microsoft Surface I was targeting, sleep state S3 didn't make sense for them because I think in that sleep state, the device would ultimately just burn battery. So the designers likely nixed it (eliminated it) for that reason.

[roboknight]

https://www.cyberciti.biz/files/linux-kernel/Documentation/power/states.txt -- So kkamagui mentions that the TPM resets in state S3, which is what bitleaker uses. However, I forgot to mention above that I learned (as it states in the link I put here), that S3 is optional. So they don't always implement it. So even if the hardware maybe vulnerable, you need to first determine if your device supports sleep state S3. If you cat /sys/power/state, I believe it lists the power states available. It won't label them S0, S1, S2, S3 and so on, but things like "freeze", "mem", and "disk". I think the state you need here might be "mem". But the link above I believe does list the appropriate name. But S3 doesn't have to be implemented... its optional. Which may be why your system is failing. Oh, and you need to check "/sys/power/mem_sleep". This file, I believe, lists the available state for "mem", the one you ACTUALLY need is "deep" (according to link). If "deep" is not available, then it likely was not implemented, and you are out of luck with bitleaker.

[roboknight]

Last note on the issue:

mem_sleep

This file contains a list of strings representing supported system suspend 
variants and allows user space to select the variant to be associated with the 
“mem” string in the state file described above.

The strings that may be present in this file are “s2idle”, “shallow” and “deep”.
The string “s2idle” always represents suspend-to-idle and, by convention, 
“shallow” and “deep” represent standby and suspend-to-RAM, respectively.

Writing one of the listed strings into this file causes the system suspend 
variant represented by it to be associated with the “mem” string in the state 
file. The string representing the suspend variant currently associated with the 
“mem” string in the state file is listed in square brackets.

If the kernel does not support system suspend, this file is not present.`

from:
https://www.kernel.org/doc/html/v4.19/admin-guide/pm/sleep-states.html The upshot of this is that if you don't find "[deep]" in /sys/power/mem_sleep and "deep" is there, then you need to select "deep" by writing "deep" to this file. If you don't find "deep" at all, then your system doesn't support sleep state S3.

[roboknight]

@kkamagui In light of what I discovered, I was thinking maybe one of your tools might, during a check for the vulnerability, check for sleep state S3 availability? It might save some time for some trying to use this code?

[dell224]

Hi roboknight,

Thank you so much for all the information you have provided. They are useful.

I have confirmed the availability of S3 deep sleep on my ThinkPad P1 laptop so I think maybe my system is patched.

I tried running the testing module (napper) and it somehow got terminated half way. Please take a look.

[roboknight]

Are you trying to run on a newer version of Ubuntu? It might be possible that you need some adjustments. There may ALSO be one other problem (I don't know for sure). Even though it uses TPM 2.0, it may STILL use V1 of the registers (they use SHA1 instead of SHA2 I think). And there is a DIFFERENT interface to those. I don't know if kkamagui set up napper to use V1 or V2 of the TPM protocol. I have run into this in a few situations (the Microsoft Surface above, for example and now a Dell Inspiron that I'm working with). V1 doesn't use the same args as V2. That MAY cause your Segmentation Fault. I'm unsure because I do NOT know anything about your particular TPM (or fTPM as the case may be). I have noted, in the case of the Inspiron, they use an fTPM and were using V1, so I had to get bitleaker to use that as well. I haven't looked that closely at the napper code to see if it supports V2 only or also would support (or even has code for) V1. If there is code for V1, it may be #ifdef'd out and you may need to recompile with that support.

[roboknight]

I just ran napper on the Dell Inspiron 15 I'm looking at. It is vulnerable... but you may need this:

`

echo 1 > /proc/sys/kernel/sysrq

echo x > /proc/sysrq-trigger

`

This is if you require UEFI signing... This will disable that. I don't think his simple script does that.

[dell224]

I just ran napper on the Dell Inspiron 15 I'm looking at. It is vulnerable... but you may need this:

`

echo 1 > /proc/sys/kernel/sysrq

echo x > /proc/sysrq-trigger

`

This is if you require UEFI signing... This will disable that. I don't think his simple script does that.

Hi roboknight,

Thanks again for the wealth of information. I've learnt a lot from you.

You are right. I was running Ubuntu 20.04 over 18.04 because of the former's capability to run it live from USB drive with persistence.

The segmentation fault is due to the missing libsapi-utils and libsapi-dev for Ubuntu 20.04. I ran the bitleaker again using 18.04 and the whole process finished without any hiccup. Unfortunately/fortunately? my Thinkpad is not vulnerable to this.

[kkamagui]

@kkamagui In light of what I discovered, I was thinking maybe one of your tools might, during a check for the vulnerability, check for sleep state S3 availability? It might save some time for some trying to use this code?

Hi @roboknight, I am very impressed by your amazing works. Thank you for sharing them. Unfortunately, there is no explicit way to check the S3 sleep mode REALLY works. As you know, the sleep mode doesn't work well on Microsoft Surface. However, we didn't know that until we tested it. In my view, the only thing we can do is just testing devices as many as we can.

[kkamagui]

I just ran napper on the Dell Inspiron 15 I'm looking at. It is vulnerable... but you may need this: `

echo 1 > /proc/sys/kernel/sysrq

echo x > /proc/sysrq-trigger

` This is if you require UEFI signing... This will disable that. I don't think his simple script does that.

Hi roboknight,

Thanks again for the wealth of information. I've learnt a lot from you.

You are right. I was running Ubuntu 20.04 over 18.04 because of the former's capability to run it live from USB drive with persistence.

The segmentation fault is due to the missing libsapi-utils and libsapi-dev for Ubuntu 20.04. I ran the bitleaker again using 18.04 and the whole process finished without any hiccup. Unfortunately/fortunately? my Thinkpad is not vulnerable to this.

Hi @dell224 , Thank you for your effort. I am glad that your Thinkpad is safe. :)

[roboknight]

@kkamagui , I was just hoping that your script might just "cat" the files I mentioned to look for the "[deep]" string. Its not a perfect check, I suppose, but if you didn't find it, then at least you might be able to say, "Hey, we're not likely to be able to make this work... you don't appear support sleep state S3. You've been warned" kind of thing. That might have saved me a lot of digging on the Surface I was looking at. Or maybe, "Linux appears to support sleep state S3 on this device. If you have trouble, verify this support." (after performing said check).

[kkamagui]

Hi @roboknight , Thank you for your idea. I just understood what you said. Your idea is registered at https://github.com/kkamagui/bitleaker/issues/5. For the next release, I will add the feature.