Driver with expired certificate

NTDEV
21

I see your point, but unless you’re REQUIRED to query the time from a definitive source from a previously defined list of definitive sources (via /T or otherwise) there’s no way to enforce this in the Digital world.

Let’s say you’re disgruntled employee who has your cert (how did she GET that cert, by the way?? If you’re the type of company where such things matter, that cert should be on a smart card – where it cannot be exported – and locked in your safe. But let’s ignore that, because that’s a discussion from another thread).

So, let’s say your disgruntled employee has your cert from the year 2009. They take their machine OFF the network, set the time back to 2009,m and sign some malware with your cert. Because they’re not online, they don’t use the /T parameter… which is, in all cases, entirely optional.

As far as the computer knows, it’s 2009. And your rouge former employee has just successfully signed their malware with your cert.

Or, even if you ARE required to query the time from SOME (but not a specific) RFC 3161 timestamp server: The rouge employee sets up a bogus timestamp server on their local LAN – And that phony timestamp server returns a phony time that matches the time to which the signing machine was set back.

I can’t think of how we could prevent these things in the current system… unless you’re REQUIRED to use a SPECIFIC timestamp server, which you are presently not.

Peter
OSR

22

xxxxx@osr.com wrote:

I see your point, but unless you’re REQUIRED to query the time from a definitive source from a previously defined list of definitive sources (via /T or otherwise) there’s no way to enforce this in the Digital world.

Of course there is. The timestamp I get from the server is signed by
the server. If that signature can be traced back to a root authority,
then it is valid. Otherwise, it isn’t.

The logic isn’t that hard. Here is the way I would have written the
KMCS check.

if( !driver_package_has_a_signature )
return STATUS_PACKAGE_NOT_SIGNED;

if( !driver_package_chain_ends_in_microsoft_code_authority )
return STATUS_PACKAGE_NOT_TRUSTED;

time_t BaseTime = time(NULL);
if( driver_package_has_a_timestamp &&
driver_package_timestamp_signature_is_trusted )
BaseTime = timestamp_from_driver();
if( driver_package_base_certificate_expiration < BaseTime )
return STATUS_CERTIFICATE_EXPIRED;

return STATUS_HAPPINESS;

That’s what I expected to happen.

So, let’s say your disgruntled employee has your cert from the year 2009. They take their machine OFF the network, set the time back to 2009,m and sign some malware with your cert. Because they’re not online, they don’t use the /T parameter… which is, in all cases, entirely optional.

Optional, yes, but it changes the behavior.

As far as the computer knows, it’s 2009. And your rouge former employee has just successfully signed their malware with your cert.

But when that driver gets LOADED, the system should be able identify it
as an expired certificate, because it doesn’t have a valid origination
timestamp.

Or, even if you ARE required to query the time from SOME (but not a specific) RFC 3161 timestamp server: The rouge employee sets up a bogus timestamp server on their local LAN – And that phony timestamp server returns a phony time that matches the time to which the signing machine was set back.

That phony timestamp server isn’t trusted by Windows.

I can’t think of how we could prevent these things in the current system… unless you’re REQUIRED to use a SPECIFIC timestamp server, which you are presently not.

It’s not hard at all. I don’t have to use a specific timestamp server,
but if I want the timestamp time to be used, then I have to use a
timestamp server that is trusted by Windows.

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

23

> -----Original Message-----

From: xxxxx@lists.osr.com [mailto:bounce-466581-
xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Friday, July 22, 2011 12:07 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Driver with expired certificate

I see your point, but unless you’re REQUIRED to query the time from a
definitive source from a previously defined list of definitive sources
(via /T
or otherwise) there’s no way to enforce this in the Digital world.

The OP, in post 7 on this thread, said: “For starters, I always sign using
the /t option. My original timestamp URL was tsa.starfieldtech.com, but I’ve
tried timestamp.verisign.com as well, they both work. If I try and sign with
the orrect time on my system’s clock, signtool fails with error code
CERT_E_EXPIRED (0x800b0101). If however I back up my system’s clock the file
is signed with no warnings or errors. What’s more, I can load this signed
driver on Windows 7 x64.”

It seems to me that signtool should be failing no matter what the system
clock on the signing box says in that case. That’s my discomfort with the
situation. A trusted time server returned a current date that is later than
the expiration date on the cert. That should not be equivalent to the
trusted time server returning a current date that is earlier than the
expiration date on the cert, no matter what the clock in the signing host
says.

Phil

Philip D. Barila

24

> The signature becomes invalid when the
> certificate expires, and the driver will not be loaded after that
> point. We have evidence from earlier in this thread that Windows does
> enforce this. <

Actually, this is not true. If you want to verify this in an
interesting way, locate a copy of Atsiv. Create a default install of
Windwos 7 x64. The Atsiv driver is signed with a certificate that was
revoked at Microsoft’s request. If you allow Windows to pull down the
CRL it won’t load. Windows does check the CRL. But you can disconnect
the Internet to prevent Windows from checking the
CRL. The Atsiv certificate has also expired and the driver was never
timestamped. So it still shouldn’t load (with the Internet
disconnected). And yet it does! Once the Atsiv driver is loaded you
can reconnect the Internet and go about loading unsigned drivers to your
hearts content.

25

SO, if signed but no timestamp == STATUS_HAPPINESS? RIght, that’s how it works now.

We’re confusing certificate validity and timestamp here.

But, in any case, you want J-Random-Big-Hardware-Vendor who supplies your NIC driver to force you to update your NIC driver every year because their cert expires annually? That’s positively HIDEOUS. This is not how the program is supposed to work. Never was.

Note that the cert expiration data in this case has nothing to do with timestamping the driver.

SO now I am once again not sure what we’re talking about. I *thought* you were talking about being able to SIGN drivers with an expired cert, which I indicated is not possible to prevent, given that you can sign drivers off line.

Now, I hear you saying you don’t want WINDOWS to load drivers, where the cert used to sign the driver has expired. That would be very bad for legacy hardware, at the VERY least.

Peter
OSR

26

xxxxx@osr.com wrote:

We’re confusing certificate validity and timestamp here.

But, in any case, you want J-Random-Big-Hardware-Vendor who supplies your NIC driver to force you to update your NIC driver every year because their cert expires annually? That’s positively HIDEOUS. This is not how the program is supposed to work. Never was.

It IS supposed to work exactly that way, **IF**
J-Random-Big-Hardware-Vendor didn’t use a validated timestamp when it
signed the driver. The evidence suggests it DOES work exactly that way
(modulo the hack described a couple of hours ago).

Note that the cert expiration data in this case has nothing to do with timestamping the driver.

Of course it does! It has EVERYTHING to do with the timestamp! That’s
the point I’m trying to make. I don’t understand where I’ve gone wrong
in my descriptions. I will try again.

Here are all of the possible combinations.

* I sign my driver with an unexpired certificate and no timestamp

This driver should load successfully until the expiration date. After
that, it should fail to load, because the (now expired) certificate is
invalid. The client could set the clock back on his system to make it
load again.

* I sign my driver with an expired certificate and no timestamp

This driver should be useless, exactly like the first case above after
the expiration date has passed.

* I sign my driver with an unexpired certificate with a timestamp

This driver should load successfully, forever. The client system can
decide whether it trusts the timestamp. If it does, it can compare the
timestamp time with the certificate time, and learn that the package was
signed while the certificate was valid, just as God intended. Eternal
happiness.

* I sign my driver with an expired certificate with a timestamp

A good argument can be made that signtool should forbid this
combination. It has enough knowledge to do so. Given that it does not,
the client system CERTAINLY has enough information. It can decide
whether it trusts the timestamp. Assuming it does, it should be
comparing the timestamp time with the certificate time, and will learn
that the package was signed after the expiration. Thus, the signature
is invalid.

SO now I am once again not sure what we’re talking about. I *thought* you were talking about being able to SIGN drivers with an expired cert, which I indicated is not possible to prevent, given that you can sign drivers off line.

Wrong. It is not possible to sign a driver WITH A VALID TIMESTAMP while
off line. Since a driver package signed without a timestamp is a
ticking timebomb, which will cease to load once the certificate expires,
I would argue that your statement is false.

Now, I hear you saying you don’t want WINDOWS to load drivers, where the cert used to sign the driver has expired. That would be very bad for legacy hardware, at the VERY least.

This IS how it works. We’ve seen it.

You continue to want to disconnect the signature from the timestamp.
You can’t do that. They are deeply entwined. The timestamp validates
the certificate. The only way to make an eternally valid driver package
is to sign it with a valid certificate and a timestamp. If you sign
without a timestamp, the driver will load today, but will fail to load
after the certificate expires. This HAPPENS.

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

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

27

OK, I *was* missing something and we’re staring to get somewhere.

I think.

I certainly appreciate the detailed description of how timestamping is supposed to affect whether the driver is loaded… not that I am not at all certain that Windows actually checks whether your cert has expired when loading your driver. I *know* it checks the CRL.

So, now we get back to the original question: You don’t want rouge employee to sign drivers using your expired certificate. My contention was simple: They just have to setup their own timestamp server, set back the time on both their signing machine and the timestamp server to a time when the cert was valid, and sign away. Presto… valid driver executable, signed and timestamped, and good forever.

I realize you said:

But, again as far as I know, this is not the way it works. ANY RFC compliant timestamp server will do.

So, I hear you arguing: (a) signtool shouldn’t let you successfully complete the signing process when a cert expires before the time/date indicated by the timestamp server, and (b) Windows shouldn’t load drivers that have expired certs and that were signed by untrusted timestamp servers.

Is that right? Because if so, after all this discussion I guess you’ve convinced me that what you’re proposing is reasonable.

Peter
OSR

28

xxxxx@osr.com wrote:

But, again as far as I know, this is not the way it works. ANY RFC compliant timestamp server will do.

That certainly cheapens the process for me. I had “assumed” someone in
the process cared about the timestamper.

So, I hear you arguing: (a) signtool shouldn’t let you successfully complete the signing process when a cert expires before the time/date indicated by the timestamp server, and (b) Windows shouldn’t load drivers that have expired certs and that were signed by untrusted timestamp servers.

Is that right? Because if so, after all this discussion I guess you’ve convinced me that what you’re proposing is reasonable.

Yep. More than a proposal, I thought that’s how things were currently
being done. Otherwise, I could not reconcile in my brain the need for a
validated timestamp. This seems like a large and rather fundamental
hole in the KMCS mechanism.

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

29

It is hard to believe that a hole of this kind and size can exist in win7.
So my guess is that there’s a deliberate (but undocumented) decision not to
check timestamps with KMCS.

Possible reasoning: allow to use standalone machines with its clock broken
or deliberately set way off to future or past.
Mitigation: keep only good certs on the machine and remove any bad certs
(revoked or expired).

– pa
(reposted)

30

> Now, I hear you saying you don’t want WINDOWS to load drivers, where the cert used to sign the driver has

expired. That would be very bad for legacy hardware, at the VERY least.

No. I understand Tim very well, and, for me (like for Tim), this also looks like a bug in Windows KMCS (or in SignTool - at least a warning would be good for such a case).

Due to obvious security issues (see Tim’s email), signing with an expired cert must fail. More so, to protect against the possibility of malformed Signtool analog, it must be checked at cert check time, i.e. in KMCS. SignTool could also issue at least a warning for this.

The whole thing about timestamping is to prevent the scenario with the signing computer with the phony local date/time (more so, this is the ONLY thing to protect against this). The thing is that the timestamp data is generated by the trusted server using PK crypto (like the cert itself), so you cannot forge it, and the timestamp is “crypto proven” to have this date/time.

The classic way of cert check is:

  • if there is no timestamp in the signature - check the local date/time against the cert expiration. Bad way, since the checks for previously valid software will fail some time in the future. But this is the only way to get around the holes.
  • if there is a timestamp - then the timestamp must NOT be later then the cert expiration. Since both date/time values are crypto-proven, one cannot forge them.

If KMCS skip this check - this is evil.

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

31

> - if there is no timestamp in the signature - check the local date/time

against the cert expiration. Bad way, since the checks for previously
valid software will fail some time in the future. But this is the only way
to get around the holes.<

What is the point of this mode? All it leads to is the risk of shipping
drivers with a cert error so they stop working at some time in the future.
This seems hard to test for as putting a test machine’s clock forward to
after the signing cert expiry seems to be reported not to work, so there is
in fact no way to test for this error.

Surely the only valid signature should include a verified time stamp?

M

>>>>>>>>>>>>>>>>>>>>>>
----- Original Message -----
From: Maxim S. Shatskih
Newsgroups: ntdev
To: Windows System Software Devs Interest List
Sent: Monday, July 25, 2011 11:13 AM
Subject: Re:[ntdev] Driver with expired certificate

Now, I hear you saying you don’t want WINDOWS to load drivers, where the
cert used to sign the driver has
expired. That would be very bad for legacy hardware, at the VERY least.

No. I understand Tim very well, and, for me (like for Tim), this also looks
like a bug in Windows KMCS (or in SignTool - at least a warning would be
good for such a case).

Due to obvious security issues (see Tim’s email), signing with an expired
cert must fail. More so, to protect against the possibility of malformed
Signtool analog, it must be checked at cert check time, i.e. in KMCS.
SignTool could also issue at least a warning for this.

The whole thing about timestamping is to prevent the scenario with the
signing computer with the phony local date/time (more so, this is the ONLY
thing to protect against this). The thing is that the timestamp data is
generated by the trusted server using PK crypto (like the cert itself), so
you cannot forge it, and the timestamp is “crypto proven” to have this
date/time.

The classic way of cert check is:

  • if there is no timestamp in the signature - check the local date/time
    against the cert expiration. Bad way, since the checks for previously valid
    software will fail some time in the future. But this is the only way to get
    around the holes.
  • if there is a timestamp - then the timestamp must NOT be later then
    the cert expiration. Since both date/time values are crypto-proven, one
    cannot forge them.

If KMCS skip this check - this is evil.

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

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

32

On 25/07/2011 11:48, Mike Kemp wrote:

> - if there is no timestamp in the signature - check the local
> date/time against the cert expiration. Bad way, since the checks for
> previously valid software will fail some time in the future. But this
> is the only way to get around the holes.<

What is the point of this mode? All it leads to is the risk of
shipping drivers with a cert error so they stop working at some time
in the future. This seems hard to test for as putting a test machine’s
clock forward to after the signing cert expiry seems to be reported
not to work, so there is in fact no way to test for this error.

Surely the only valid signature should include a verified time stamp?

From a practical point of view, time-stamping a large number of files
can take a long time so skipping that step for short-lived builds can be
useful.

–
Bruce Cran

33

> 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.

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

34

>

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.

James

35

>

> Now, I hear you saying you don’t want WINDOWS to load drivers, where
the
cert used to sign the driver has
>expired. That would be very bad for legacy hardware, at the VERY
least.

No. I understand Tim very well, and, for me (like for Tim), this also
looks
like a bug in Windows KMCS (or in SignTool - at least a warning would
be good
for such a case).

Due to obvious security issues (see Tim’s email), signing with an
expired cert
must fail. More so, to protect against the possibility of malformed
Signtool
analog, it must be checked at cert check time, i.e. in KMCS. SignTool
could
also issue at least a warning for this.

The whole thing about timestamping is to prevent the scenario with the
signing
computer with the phony local date/time (more so, this is the ONLY
thing to
protect against this). The thing is that the timestamp data is
generated by
the trusted server using PK crypto (like the cert itself), so you
cannot forge
it, and the timestamp is “crypto proven” to have this date/time.

The classic way of cert check is:

  • if there is no timestamp in the signature - check the local
    date/time
    against the cert expiration. Bad way, since the checks for previously
    valid
    software will fail some time in the future. But this is the only way
    to get
    around the holes.
  • if there is a timestamp - then the timestamp must NOT be later
    then the
    cert expiration. Since both date/time values are crypto-proven, one
    cannot
    forge them.

If KMCS skip this check - this is evil.

How many such ‘evil’ drivers are there in existence at this time? If MS
released a patch to correct the above anomaly, what would break?

James

36

>

What is the point of this mode? All it leads to is the risk of shipping
drivers with a cert error so they stop working at some time in the
future. This seems hard to test for as putting a test machine’s clock
forward to after the signing cert expiry seems to be reported not to
work, so there is in fact no way to test for this error.

Surely the only valid signature should include a verified time stamp?

One reason is if you want your driver to stop working when the signing
certificate expires. For example, the authors of Atsiv release this
driver to make a point about the limitations of KMCS and the
disproportionate impact which this policy may have on small developers.
On the other hand, Atsiv has the potential for abuse since it allows
for loading unsigned code. The Atsiv authors may have intentionally
refrained from timestamping their driver secure in the knowledge that it
would stop working in a year in any event. I am only speculating, of
course. But it is one possible reason.

37

“James Harper” wrote in message
news:xxxxx@ntdev…
>>
>> 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.
>
> James

Yep. Just one reason to separate procedures of building binaries and
signing.
–pa

38

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.

39

James Harper wrote:

How many such ‘evil’ drivers are there in existence at this time? If MS
released a patch to correct the above anomaly, what would break?

I’ll go out on a limb and say “nothing”. I should do a survey of the
drivers in my Win 7 64 machine to find out real numbers, but I’ll wager
there’s not a one of them that doesn’t have a certified timestamp.

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

40

Bruce Cran wrote:

On 25/07/2011 11:48, Mike Kemp wrote:
> Surely the only valid signature should include a verified time stamp?
From a practical point of view, time-stamping a large number of files
can take a long time so skipping that step for short-lived builds can be
useful.

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.

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