GTX 1070 Firmware Overwritten by Malware - Unable to Reset

[Flanker]

What are the chances of jumpers becoming a super duper new security feature of next generations of motherboards? Probably the coolest thing since solid capacitors?

 

[cadaveca]

And supposedly, protect them, which they have historically done horribly. It's a google away how to dump one with a simple serial port.

Serial port plug in or physical jumper can be secured in the same way. It's kinda wishy-washy.

I think the user should be presented with a more secure (ie write protected) default.

Why? I have no faith in the standard end user.

PS: I like how you have brought the TPM argument into this despite the fact they have nothing to do with firmware validation.

With TPM UEFI can prevent these problems. But because it is not present it is not implemented. For me, it's not about having faith in the end user. For me, it's the product maker's responsibility to ensure stuff like this isn't an issue.

UEFI began as Intel's baby.


The fact you don't tie the two together here is why I bring it up.

 

[R-T-B]

With TPM UEFI can prevent these problems.

But why the need for the black box?

I believe the most secure system is the one where everyone can know exactly how it works and still not be able to compromise it. I don't like "hardware security" when historically, software can do it well and has. Verifying hashes is something our CPUs do every day.

 

[cadaveca]

But why the need for the black box?

Because it offers the physical cryptographic security required that cannot be bypassed, except physically, and because of the key used, can be far more secure than just a jumper. a jumper I can move, but a cryptokey I have to crack first before I move the jumper. BIOS first BOOT phase is security verification (SEC)... all this can happen then, and is far better than a jumper. It can also prevent BIOS flashing and all of that.

Unless this sort of stuff is happening, you can't prevent stuff like this. That's all I'm saying. The tech exists already, even. So if you haven't taken the steps to utilize it, it's rather contradictory to ask for it.

 

[R-T-B]

Because it offers the physical cryptographic security required that cannot be bypassed, except physically, and because of the key used, can be far more secure than just a jumper. a jumper I can move, but a cryptokey I have to crack first before I move the jumper. BIOS first BOOT phase is security verification (SEC)... all this can happen then, and is far better than a jumper. It can also prevent BIOS flashing and all of that.

Let me elaborate further:

I don't see any reason TPM adds ANY security to a simple hash check. I actually feel if anything, it adds a layer of complexity with which to attack. If anything, a larger attack surface is never better, and security through obscurity is not security. These are proven concepts.

So if you haven't taken the steps to utilize it, it's rather contradictory to ask for it.

My client did utilize secure boot, FWIW. It was shut off via a simple malware cmos write.

Want a fun factoid?

There are no means in present uefi to validate CMOS. At all.

 

[GC_PaNzerFIN]

Let me elaborate further:

I don't see any reason TPM adds ANY security to a simple hash check. I actually feel if anything, it adds a layer of complexity with which to attack. If anything, a larger attack surface is never better, and security through obscurity is not security. These are proven concepts.

Obviously having a black box does not work. That is why a lot of old and even recent machines shipped with TPM modules, that produce keys that are easy to crack.
Because it was a black box, only one to discover this was someone actually trying to exploit it. Oh, too easy!

 

[cadaveca]

Let me elaborate further:

I don't see any reason TPM adds ANY security to a simple hash check. I actually feel if anything, it adds a layer of complexity with which to attack. If anything, a larger attack surface is never better, and security through obscurity is not security. These are proven concepts.

again, look at my last post. The first thing a UEFI BIOS does is a security check. It's not that complicated at all, and it's not an added layer. It's a missing one. It even is supposed to flush CPU cache to anything left over isn't executed. But you need a key somewhere that everything (the UEFI firmware modules) is verified against, and a TPM is the place to store it.

Obviously having a back box does not work. That is why a lot of old and even recent machines shipped with TPM modules, that produce keys that are easy to crack.
Because it was a back box, only one to discover this was someone actually trying to exploit it. Oh, too easy!

Naturally. We are talking about very simple electric circuits when you really boil it all down. If you know how to design these things, none of this is incredibly deep. It is a simple lack of understanding that makes it seem complicated. That's why I do reviews... to help get information out that is easily accessible. This isn't some magic some programmer does.

 

[GC_PaNzerFIN]

again, look at my last post. The first thing a BIOS does is a security check. It's not that complicated at all, and it's not an added layer. It's a missing one.
Naturally. We are talking about very simple electric circuits when you really boil it all down. If you know how to design these things, none of this is incredibly deep. It is a simple lack of understanding that makes it seem complicated. That's why I do reviews... to help get information out that is easily accessible.

By far the largest security holes have been due to lack of proper documentation or misunderstanding of unclear documentation provided by a certain processor manufacturer. Known issue, still a problem.

 

[R-T-B]

again, look at my last post. The first thing a BIOS does is a security check. It's not that complicated at all, and it's not an added layer. It's a missing one.

SEC phase is a joke that has basically turned into a memory initialization phase.

Actually, the latest description in any UEFI docs (third party or otherwise) describes it as follows:

This contains all the CPU initialisation code from the cold boot entry point on. It’s job is to set the system up far enough to find, validate, install and run the PEI.

Not much mention of security. Technically, I guess "validation" should fill this role but DXEs aren't validated, which is entirely where this attack took place.

At any rate there is no reason this validation needs a TPM, which was my point from the beginning here.

 

[cadaveca]

SEC phase is a joke that has basically turned into a memory initialization phase.

Actually, the latest description in any UEFI docs (third party or otherwise) describes it as follows:



Not much mention of security.

validate is security...?

 

[R-T-B]

validate is security...?

I clarified. It doesn't validate DXEs.

At any rate this is incredibly off topic. I'm only cleaning a clients computer and reporting my findings as I do. I don't find this particularly earth shattering (though it certainly is interesting) but do think there are lessons in it for future development. Take from that what you will.

 

[cadaveca]

I clarified. It doesn't validate DXEs.

So we are now back to where we began in that you can't overcome these problems, so you're wasting your time.

I'm pretty familiar with where all these holes are present. Now, because in UEFI, flashing is done via a module within the UEFI, we have a very clear path on how you can flash a BIOS with malware to a board without much difficulty, without going into much detail as to how it is actually done.

Add in to it that a MAC id identifies that board specifically, and you easily show how that board is pretty much a hole that needs to be thrown out. Since it had already been compromised, there is no real way of fixing this in the long term. You can remove the current infection if there IS one present, but that doesn't prevent the same from ever happening. If that board was compromised once, it can be again, and nothing you can do can prevent it. whoever did that, if true, can always do it again, whenever they want.

 

[R-T-B]

So we are now back to where we began in that you can't overcome these problems, so you're wasting your time.

No. I can clean his computer fine. Already nearly there.

I just think there are lessons here. And there's certainly a way to build a better mousetrap, so to speak. Heck, let me quasi design one for you right now: Flash a OTP flash chip with a key and have that be the root of trust for sig validation. Cheap effective and can't really be hacked.

Maybe I'm just not as pessimistic as you Dave.

 

[cadaveca]

No. I can clean his computer fine. Already nearly there.

I just think there are lessons here. And there's certainly a way to build a better mousetrap, so to speak. Heck, let me quasi design one for you right now: Flash a OTP flash chip with a key and have that be the root of trust for sig validation. Cheap effective and can't really be hacked.

Maybe I'm just not as pessimistic as you Dave.

No, it's that you don't understand that every BIOS is supposed to have a key anyway. that's how a flasher knows a BIOS isn't for a particular board in the first place. You wouldn't be doing anything but the exact same thing. Every BIOS is signed and that signature is checked. That's part of what UEFI offers in the first place.

It's not pessimistic at all. Being pessimistic would be telling you that the OP knew all this before he even posted here and just wanted to see how far it could go.

It's just a matter of making it clear that there's not much to be done here that board makers aren't doing already.

 

[R-T-B]

You can remove the current infection if there IS one present, but that doesn't prevent the same from ever happening.

You are incorrect on that front, is all I can say at the moment.

No, it's that you don't understand that every BIOS is supposed to have a key anyway. that's how a flasher knows a BIOS isn't for a particular board in the first place. You wouldn't be doing anything but the exact same thing.

I bypass those keys all the time (those that actually are uh, implemented).

They aren't "keys." They are bloody file hashes at best.

that's how a flasher knows a BIOS isn't for a particular board in the first place.

Nope. It's a bloody string in the DMI fields, at least in Aptio V, which is what most boards today use.

To be exact, it is this string:

Every BIOS is signed and that signature is checked. That's part of what UEFI offers in the first place.

Oh god. You don't really believe that, do you?

Go play with an EVGA bios for 5 minutes (no sig check at all). Or a gigabyte. Their sigcheck is literally a BOOLEAN FLAG.



To find a gigabyte sig check, you open the bios with a hex editor. You search for the string "$BDR." You will see your board name. After that, a long hexadecimal string of zeroes. The boolean flag that says whether all is well or not is literally the second "01" after the long line of zeroes.

 

[cadaveca]

Oh god. You don't really believe that, do you?

Go play with an EVGA bios for 5 minutes. Or a gigabyte. Their sigcheck is literally a BOOLEAN FLAG.

Lazy BIOS programmers focused on overclocking before security are not what I am talking about. the unfortunate truth is that design standards are not the same as implementations. There are several people I follow that are focused on these sorts of things directly, and this is a common complaint.

 

[R-T-B]

Lazy BIOS programmers focused on overclocking before security are not what I am talking about. the unfortunate truth is that design standards are not the same as implementations. There are several people I follow that are focused on these sorts of things directly, and this is a common complaint.

ASUS is the only one I've ever seen with a half assed sigcheck.

It still can be bypassed with a few tricks.

Supermicro and server vendors are just as guilty. They are all based on the same codebase, really. Aptio V has become the reference standard and it's a bug infested fruit.

 

[trparky]

So like what prevents one from flashing the wrong UEFI update file to a motherboard? What stops someone from flashing an ASUS update to an MSI board?

 

[R-T-B]

So like what prevents one from flashing the wrong UEFI update file to a motherboard? What stops someone from flashing an ASUS update to an MSI board?

The DMI strings in the bios must match board and vendor.

I mean, that's how it's usually done. The argument here is kind of that there should be something better.


...

and since I realized I've just possibly broken a sweat in a debate about computer bioses, I'm stepping away from the keyboard for now. Later all.

 

[cadaveca]

So like what prevents one from flashing the wrong UEFI update file to a motherboard? What stops someone from flashing an ASUS update to an MSI board?

For me, personally, nothing.

ASUS is the only one I've ever seen with a half assed sigcheck.

It still can be bypassed with a few tricks.

Supermicro and server vendors are just as guilty. They are all based on the same codebase, really. Aptio V has become the reference standard and it's a bug infested fruit.

This is funny to me because we basically agree about the facts, but not the semantics.

Some products are secure, and some are not. But I can overcome all of those, really, so nothing is secure. There are people getting paid to do this sort of testing, but you need an invite or you don't get paid and any work you do will simply get taken by someone that IS getting paid. A critical hardware flaw pays about 40k, FYI. Firmware stuff is about 25% of that.

 

[R-T-B]

A critical hardware flaw pays about 40k, FYI. Firmware stuff is about 25% of that.

And for me, it literally pays 20 bucks an hour (sometimes, when I get a client) and the warm and fuzzy feeling I did some good for the world.

If you ever thought I was in this for the money, you thought wrong.

 

[cadaveca]

And for me, it literally pays 20 bucks an hour and the warm and fuzzy feeling I did some good for the world.

If you ever thought I was in this for the money, you thought wrong.

Doing it for money is ALL you should be doing. Your time is valuable. But someone might take that time you've spent and use that to get paid for nothing. There are conventions for doing this sort of stuff, with one coming real soon!

So yeah, I'm actually thinking the opposite of what you suggest here.

and since I realized I've just possibly broken a sweat in a debate about computer bioses, I'm stepping away from the keyboard for now. Later all.

It's just a discussion LULz, don't take it too seriously, really. Like you know, a couple of Intel firmware bugs can pay my bills for the year. And I get the hardware for free... so I can stay up with the tech and get access before the public does...

 

[R-T-B]

Doing it for money is ALL you should be doing.

Don't tell me what to do!

 

[revin]

So let me understand, my Intel DZ77GA "Has" a Jumper for BIOS it has to be positioned to even allow any changes, AND a position to actually "Update" the BIOS, is this current issue able ot get around the Jumper Lock for a BIOS Update ?

 

[MrGenius]

The jumper manually enables/disables the write protect pin on the EEPROM chip. Preventing/allowing it being written to. This can't be overridden by software/firmware. It requires an electrical connection to the pin is made via the jumper to disable write protection. There's no way for software/firmware to make the physical electrical connection and override the write protect feature. Therefore, it would be 100% impossible to flash a BIOS with the jumper in the LOCK(or whatever it's called) position.

EDIT: And this is not difficult to implement on any board that lacks it. Cut the pin's connection to the board. Add switchable circuit between board and pin(or pin and ground, pin and power, whichever's required). Done.