Driver with expired certificate

[mm1]

There are situations where internet is not really possible.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Monday, July 25, 2011 12:59 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Driver with expired certificate

James Harper wrote:

> Surely the only valid signature should include a verified time stamp?
>
As astonishing as it may be, not everywhere has reliable internet
these days, or any internet. It would suck to not be able to build and
test just because your internet happened to be down.

I don’t care. It’s a cost of doing business. You can certainly TEST your
mis-signed driver, using the current bypass techniques, but if you want to
play in the real world, you buy a certificate, and you do the signing on a
machine with a connection to the Internet.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

---

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

[Tim_Roberts]

M. M. O’Brien wrote:

There are situations where internet is not really possible.

For the record, I’m not arguing that signing should be impossible
without a validated timestamp.

However, the situation you’re describing is not the real world. That
world is tightly controlled, and accustomed to living with unusual
restrictions. A developer in that world will just have to get used to
re-releasing drivers every time their certificate renews. A company
developing in such an environment should never release its drivers into
the wild, and in reality would probably never expect to do so.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

[Maxim_S_Shatskih]

>As astonishing as it may be, not everywhere has reliable internet these

days, or any internet.

And? For me, it should be OK to have no timestamp at all. It should not be OK to timestamp the binary using expired cert and phony clock.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

[OSR_Community_User]

On 25/07/2011 18:03, Tim Roberts wrote:

I don’t see how that could possibly be a real-world concern. The
number of files in a driver package that need to be signed is never
going to be more than a dozen or two (even for HP, who loves enormous
driver packages). The total time for timestamping is going to be
measured in seconds, not minutes.

I know there are times when I’ve found the timestamp server has been
taking several seconds per call, or just times out. So I have gone to
the effort of adding an option to my build scripts to disable timestamping.

–
Bruce Cran

[OSR_Community_User]

On 07/22/2011 11:58 PM, xxxxx@osr.com wrote:

ANY RFC compliant timestamp server will do.

Signtool likely does not care about whether the timestamp has a valid
certificate chain up to the trusted store. (And it does not need to, see
below.)

But Windows’ driver loading mechanism should care, and only accept a
timestamp that has an unbroken certificate chain up to a trusted root.

This could include a scenario where you run your own timestamp server
and have a certificate chain installed on your own companies’ clients
that trust that timestamp server and thus accept these timestamps.

But for any out-of-the-box Windows installation, there should only be a
few - e.g. GlobalSign and VeriSign - certificate chains present.

[Please note that very often you can’t check on your development/signing
machine if a certificate will be accepted by a “fresh” Windows
installation: Signtool imports e.g. cross-certificates locally during
signing. So on_the_signing_machine every cert needed for checking will
be present. (I had the case where a colleague could install but not load
a driver on Win7/64bit - and on my machine it “verified” successfully.)]

(a) signtool shouldn’t let you successfully complete the signing
process when a cert expires before the time/date indicated by the
timestamp server

Well, in my opinion in this case it would benice if Signtool would print
a warning that the certificate used for signing is expired.

But for the security discussion it is actually totally unimportant what
any Signtool will let you do or not !

=> If you want real security, your signature checking system must also
work if someone else writes their own signing tools.

It is solely the driver installation and load code that must check
properly if all certificate chains are “unbroken”.

(b) Windows shouldn’t load drivers that have expired certs and that
were signed by untrusted timestamp servers.

Windows should not load drivers that have expired certs. AND
(Windows should not load drivers that have expired certs) that (are
timestamped to have been signed before they were expired) by untrusted
timestamp servers.

I can understand if there is an exception to load not-timestamped
drivers before a trusted time source is available.

Otherwise a wrongly set system clock could prevent you from booting at
all. Checking the file datestamp also does not help, this too could have
been affected by a wrong clock setting.

(There should, however, be an Administrator setting (enforcable by
policy or whatever) that prevents expired drivers from loading when
there is no trusted time source available.)

But if a “trusted” timestamp is present and its time is AFTER the driver
certificate expiration date, then load must be rejected.
Otherwise the system is already compromised.

[OSR_Community_User]

On 07/22/2011 11:27 PM, Tim Roberts wrote:

If not, what’s the point of the timestamp?

The function of a (cryptographic) timestamp is to prove that a given
amount of data existed at a given point in time.

For drivers, this is useful, because with a trusted timestamp present,
an automated signature checking system can decide to accept an already
expired certificate if the (trusted) timestamp indicates the certificate
was valid “at the point in time” when it was used for signing.

A cryptographic timestamp could also be used for other purposes, e.g. to
(cryptographically) prove that some data or document or idea (written
down in a document) existed at a given point in time. If you want to
save patent fees, but want to be able to prove “prior art” in case
someone sues you, crypto-timestamp your design documents…

But a cryptographic timestamp does not establish the identity of the
owner/signer of a “data item” (only the time/date and the identity of
the TSA…).

For the identity of the owner/signer of a “data item”, you need a
signing certificate that is counter-signed by someone trusted “higher
up” in the certificate chain.

[Tim_Roberts]

Hagen Patzke wrote:

On 07/22/2011 11:58 PM, xxxxx@osr.com wrote:
> ANY RFC compliant timestamp server will do.
Signtool likely does not care about whether the timestamp has a valid
certificate chain up to the trusted store. (And it does not need to, see
below.)

Actually, the discussion we’ve had here has changed my opinion somewhat
about several aspects of this.

Signtool with /t is going to be run with an Internet connection. It has
the time and the ability to validate the timestamp trust level. If the
timestamp source is trusted, then signtools should be using THAT time
source to check the expiration date on the certificate.

But Windows’ driver loading mechanism should care, and only accept a
timestamp that has an unbroken certificate chain up to a trusted root.

Remember that the reason we have to use a cross-certificate is because
it is too time-consuming for the KMCS check to search the trusted root
chain. The certificate chain has to end at exactly one root certificate
– the one at the other end of ALL of the cross-certificates.

So, it’s not reasonable for me to insist that KMCS do a trusted root
search for the timestamp certificate chain. Given that, I’m not sure
how I would expect this to work. I guess I have to admit that any
certified timestamp source should be trusted. Given that, there will
always be an opportunity to set up a certified time source that lies
about the current time. I don’t see a good way around it.

> (a) signtool shouldn’t let you successfully complete the signing
> process when a cert expires before the time/date indicated by the
> timestamp server
Well, in my opinion in this case it would be nice if Signtool would print
a warning that the certificate used for signing is expired.

But for the security discussion it is actually totally unimportant what
any Signtool will let you do or not !

I disagree. Signtool is part of the security process. It’s true that I
could write my own signtool replacement and subvert the checking its
doing, but it would be easier to write my own timestamp server.

=> If you want real security, your signature checking system must also
work if someone else writes their own signing tools.

It is solely the driver installation and load code that must check
properly if all certificate chains are “unbroken”.

I no longer think this is practical.

But if a “trusted” timestamp is present and its time is AFTER the driver
certificate expiration date, then load must be rejected.
Otherwise the system is already compromised.

I agree with this, but I’m now willing to expand the meaning of
“trusted”. I don’t think it’s necessary for KMCS to validate the
timestamp certificate chain. It’s too time-consuming.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

[Freezer]

Wow, my thread has really taken off since last I had a chance to check it. In message #10 I listed the two issues as I saw it. First that signtool could be made to sign with an expired certificate, and second that Windows would load a device driver that was signed with an expired certificate. I originally assumed the latter was the real problem, but I now believe that both of these are issues that should be resolved.

My guess is the Windows kernel team had a difficult time decided how it should verify signed drivers. Obviously we’re talking about twilight time here, so assume no network access of any type. The only source of the current time is the BIOS clock, which can be wrong. And since denying a driver the ability to load could be fatal for the system, I’m guessing the kernel team decided to only check for valid certificates, and not check any timestamps. Herein lies the problem with the kernel. You don’t need the current time to know if the driver was signed with an expired certificate. If I view the properties of my new driver I can clearly see that the time it was signed is *after* the certificate expired (both of which are contained in the signed binary). It doesn’t matter what the current system time is, this driver is not properly signed and should not load.

The other issue is signtool permits one to sign using an expired certificate even when using a trusted Internet time server. Granted you have to manually tweak your system time to do it, but under no circumstances should signtool permit this.

FWIW, I’m using signtool.exe version 6.1.7600.16385. I’m guessing the problem isn’t signtool per se, but the underlying sign APIs (like SignerSign). The worst part is, even if Microsoft fixes this issue, the damage is already done. Sure they could fix it and release a hotfix, but anyone who wanted to maliciously sign using this technique could just sign on a system without that hotfix installed.

Does anyone know the best way to report these issues to Microsoft? Should I just post the issue on their forums and let their technical staff go from there?

[OSR_Community_User]

On 07/27/2011 07:36 PM, xxxxx@gmail.com wrote:

Does anyone know the best way to report these issues to Microsoft?

The best way for Microsoft is likely to open a support incident with
them. This will cost you $100.

A way which worked for me in the past is to send a note to the WDK team

• these issues/findings are not properly documented, after all…

[OSR_Community_User]

On 07/27/2011 07:18 PM, Tim Roberts wrote:

I disagree. Signtool is part of the security process.

WHQL is part of the security process, if you will. But not Signtool.

Signtool is just a tool, a wrapper around the signing API.

It’s true that I
could write my own signtool replacement and subvert the checking its
doing, but it would be easier to write my own timestamp server.

No, probably you can get open source for a TSA server.
The timestamp *server* is irrelevant.

The *timestamp* must be checked if its certificate chain ends at a
trusted root.

Your bogus timestamp server will not have a certificate chain that ends
at to “trusted root”. Or you will at least be identifiable by its
signature, and can then be sued if necessary.

> => If you want real security, your signature checking system must also
> work if someone else writes their own signing tools.
>
> It is solely the driver installation and load code that must check
> properly if all certificate chains are “unbroken”.

I no longer think this is practical.

Well, it is exactly what the kernel does when checking “embedded
signatures”. I don’t talk remote-checking with external certificate
servers here, just embedded certs and the certs from the registry.

No rocket science, and not specially slow.

If you really need to speed up driver load, you could have a “driver
cache” or “preload” that is protected with a single signature.
MS probably already has that.

> But if a “trusted” timestamp is present and its time is AFTER the driver
> certificate expiration date, then load must be rejected.
> Otherwise the system is already compromised.

I agree with this, but I’m now willing to expand the meaning of
“trusted”. I don’t think it’s necessary for KMCS to validate the
timestamp certificate chain. It’s too time-consuming.

No, checking a certificate chain or a timestam chain is not very time
consuming. We are talking max. 8-10 certificates here.

A few milliseconds at most. Nothing relevant when compared to overall
boot/load time.

[Tim_Roberts]

Hagen Patzke wrote:

On 07/27/2011 07:18 PM, Tim Roberts wrote:
> I disagree. Signtool is part of the security process.
WHQL is part of the security process, if you will. But not Signtool.

Signtool is just a tool, a wrapper around the signing API.

We will have to agree to disagree.

The *timestamp* must be checked if its certificate chain ends at a
trusted root.

Your bogus timestamp server will not have a certificate chain that ends
at to “trusted root”. Or you will at least be identifiable by its
signature, and can then be sued if necessary.

As far as I know, the timestamp that is embedded in my binary does not
include a “certificate chain”. It includes one certificate. Signtool
certainly has the ability to trace that certificate back to a trusted
root. It’s not clear that the KMCS checker does.

Well, it is exactly what the kernel does when checking “embedded
signatures”. I don’t talk remote-checking with external certificate
servers here, just embedded certs and the certs from the registry.

I don’t think it does. The certificate chain is embedded in the binary,
and must end in the “Microsoft Code Verification Root”. That’s why the
cross-certificate is necessary.

No, checking a certificate chain or a timestam chain is not very time
consuming. We are talking max. 8-10 certificates here.

A few milliseconds at most. Nothing relevant when compared to overall
boot/load time.

But there are dozens and dozens of kernel modules loaded during boot.
That’s a heck of a lot of certificate chasing.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

[OSR_Community_User]

On 25/07/2011 13:15, Maxim S. Shatskih wrote:

> From a practical point of view, time-stamping a large number of files
> can take a long time
Insignificant amount of time compared to building.

Normally yes - but for example this morning timestamping using the
Verisign server is taking 13 seconds per file.

–
Bruce Cran