Daniel Terhell wrote:
What do multiprocessors and race conditions have to do with code
signing ? What is your argument ?
Gary was just being a little snide. Nothing good will come out of
pursuing this, and I suggest you both simply drop your weapons and walk
away.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> That’s just not technically correct. Signing the install kit (a) absolutely
identifies you as the origin of the driver, (b) indicates that the driver,
INF, etc have not been tampered with by a third party.
(a) and (b) are both solved by getting your software from a legitimate source. You don’t need signing to achieve those things and besides, signing has many weaknesses, some of which I will touch one below.
(1) If all you are going by is a certificate then signing gives you a false sense of security in the case something bad is signed and leaks out and spreads. (2) You can defeat signing by getting around the certificate popup and popping up an artificial certificate using a dialog editor that looks like the real deal. (3) there are at times unintelligible messes to install signed software first approving company A’s installer, then approve company B’s driver signed by a consultant, and approve company C who is the certificate authority. This caves in the poor users confidence in what they are dealing with, not enhances it.
So unless I am missing something, ignoring the signatures and getting your software from a legitimate source is your best methodology. And if you need to distribute a test version of something, then for heavens sake provide a clear and coherent dialog telling the user exactly about the limitations of what they are getting. Don’t use a test signature as some kind of cop out for doing it right because test signatures are not self explanatory and unfairly burden the end user of the awkward setup. Again, it’s creating a problem that doesn’t exist.
Just because you obtain software from a legitimate source does not mean
it hasn’t been tampered with. Any company’s
download center is at risk of being hacked. Just because you downloaded
something from company X’s website does
not ensure the executable wasn’t patched by a hacker (term used
loosely). Hell, you talk about getting software from legitimate
sources - Apple delivered a windows virus pre-installed on Ipods several
months ago
(http://www.applematters.com/index.php/section/comments/the-ipod-virus-apple-arrogance/).
Point is, just because you
obtain something from a legitimate source is meaningless.
The point about the digital signature dialog being spoofed - I’m not
sure I understand what your talking about. The system has to
already be compromised and have an executable running - I’m not sure
what this has too do with validating something during the install process.
This argument is moot, the point of a digital signature is you validate
before you run anything…
I’m not sure what your saying about test signatures; that is entirely
for in-house testing. Furthermore, this guy that is running around
signing test builds with a real certificate… hehe, sounds like his
company isn’t properly securing their cert and it would probably
be rather easy to steal. A stolen certificate is worth a pretty
penny… At least 3x the original value… And another thing,
why would anyone release a beta/test driver to a customer?
xxxxx@email.com wrote:
>That’s just not technically correct. Signing the install kit (a) absolutely
>identifies you as the origin of the driver, (b) indicates that the driver,
>INF, etc have not been tampered with by a third party.
>
>(a) and (b) are both solved by getting your software from a legitimate source. You don’t need signing to achieve those things and besides, signing has many weaknesses, some of which I will touch one below.
(1) If all you are going by is a certificate then signing gives you a false sense of security in the case something bad is signed and leaks out and spreads. (2) You can defeat signing by getting around the certificate popup and popping up an artificial certificate using a dialog editor that looks like the real deal. (3) there are at times unintelligible messes to install signed software first approving company A’s installer, then approve company B’s driver signed by a consultant, and approve company C who is the certificate authority. This caves in the poor users confidence in what they are dealing with, not enhances it.
So unless I am missing something, ignoring the signatures and getting your software from a legitimate source is your best methodology. And if you need to distribute a test version of something, then for heavens sake provide a clear and coherent dialog telling the user exactly about the limitations of what they are getting. Don’t use a test signature as some kind of cop out for doing it right because test signatures are not self explanatory and unfairly burden the end user of the awkward setup. Again, it’s creating a problem that doesn’t exist.
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
“MM” wrote in message news:xxxxx@ntdev…
> Just because you obtain software from a legitimate source does not mean it
> hasn’t been tampered with. Any company’s
> download center is at risk of being hacked. Just because you downloaded
> something from company X’s website does
> not ensure the executable wasn’t patched by a hacker (term used loosely).
> Hell, you talk about getting software from legitimate
> sources - Apple delivered a windows virus pre-installed on Ipods several
> months ago
> (http://www.applematters.com/index.php/section/comments/the-ipod-virus-apple-arrogance/).
> Point is, just because you
> obtain something from a legitimate source is meaningless.
I’ve been obtaining software from legitimate sources for decades. Never a
problem. This whole cert/signing thing is a revenue stream for M$ and their
partner.
The original excuse was driver quality, which didn’t change as a direct
result. It has morphed into a DRM thing and will only be a temporary
slow-down if any at all.
>
> The point about the digital signature dialog being spoofed - I’m not sure
> I understand what your talking about. The system has to
> already be compromised and have an executable running - I’m not sure what
> this has too do with validating something during the install process.
> This argument is moot, the point of a digital signature is you validate
> before you run anything…
>
> I’m not sure what your saying about test signatures; that is entirely for
> in-house testing. Furthermore, this guy that is running around
> signing test builds with a real certificate… hehe, sounds like his
> company isn’t properly securing their cert and it would probably
> be rather easy to steal. A stolen certificate is worth a pretty penny…
> At least 3x the original value…
This proves the point you’re arguing against …
> And another thing,
> why would anyone release a beta/test driver to a customer?
>
This was already addressed
What I think that is probably going to happen is that some hacker is going
to write some makecert utility which makes REAL fake certificates and posts
the utility to some warez group. The honor that is to be gained by this is
provocative.This will turn the whole code signing thing into a comedy (for
me already it is) and the process worthless. Also getting a certificate with
a stolen passport or a forged copy and a prepaid credit card is not
difficult, you will see that soon such illegal certificates will start
circulating and MS needs to take measures against them.
As some very skilled reverse engineer has pointed out on his site also
PatchGuard can be disabled. Kernel patching and hooking is currently
privileged to malware authors only. The security products have no abilities
to detect these because there are no methods or the risks are too high, a
problem that malware authors don’t have, all of which resulting in an even
further compromised system.
What is worse is that all these measures are also dramatically depriving
free innovation. I heard Vista SP1 is coming out with a object creation
callback which is nice but really not enough.
What I believe which DOES work (not really against malware but against
malfunctioning drivers) and also addresses the fact that MS is so often
being blamed for malfunctioning 3rd party software is a forced Driver
Verifier test the first time you install a new 3rd party driver for say a
number of minutes or number of IRPs depending on the type of driver.
Driver test tools such as NtCrash (why did they take this offline after
acquiring Sysinternals ?) and crash analysis tools should be
made comprehensible and standard so the guilty driver wil be more put to
blame. Currently blue screens are disabled by default, the majority of
consumers always thinks his computer was resetting because of a hardware
failure or because ‘Windows is so crappy’. The majority of crashes is caused
by malfunctioning hooking spyware tools, a simple NtCrash test will reveal
these.
Version info and path of every driver should be retrieved at load time and
stored to be made availalble on blue screens and in minidumps. If a blue
screen will display ‘Most likely spyware hero of blabacorp has stopped
working because of faulty device driver xxx.sys in
c:\Windows\System32\Drivers.’ the company will be left hanging and well be
pressurized to improve its product. Of course these measures do have some
implications such as in the case of a wrongly blamed driver or an OS bug but
these issues can be dealt with one way or another.
/Daniel
“BobF” wrote in message news:xxxxx@ntdev…
> I’ve been obtaining software from legitimate sources for decades. Never a
> problem. This whole cert/signing thing is a revenue stream for M$ and
> their partner.
>
> The original excuse was driver quality, which didn’t change as a direct
> result. It has morphed into a DRM thing and will only be a temporary
> slow-down if any at all.
>
Daniel Terhell wrote:
What I think that is probably going to happen is that some hacker is
going to write some makecert utility which makes REAL fake certificates
and posts the utility to some warez group.
That can’t be done… or at least not without the discovery of
new mathematics. Its not just a case of reverse engineering.
Indeed I believe the details of certificates is all in the public
domain. The problem is, even with complete knowledge of the
details, the calculations necessary to fake the signing
with a private key, when you know only the corresponding
public key, is beyond the capability of even the full
resources of most governments computing resources,
in reasonable time.
and
STOP stop stop stop stop. Be clueful or be quiet.
First: MSFT doesn’t derive any revenue from driver signing. In fact, it’s a COST for them. Maybe it does generate revenue for the Verisigns of the world. But I rather doubt MSFT cares.
Next: Know that few people here are trying to DEFEND the overall practice of *requiring* drivers to be signed to run on 64-bit Vista. I sure as hell am not defending it.
IF you’ve been following this whole Vista-64 driver signing requirement from the beginning, you’all already know that I’m not a big fan of the program. The community worked hard, and I personally worked VERY hard, to get the program modified so it had terms (like test signing, in fact) that we can live with.
Finally: THE most secure systems use non-network connected, quarantined, machines that only have software installed from CD that is obtained directly from the vendor. The images on these CDs are checksummed and the checksums are provided via a separate channel, so they can be independently validated become access. I know companies that do this.
So, like, the people who run these systems are stupid? They should just download thier software from a “reputable source” and save themselves a lot of time, effort, and annoyance??
Lacking the level of physical security I just described, insuring a driver package is signed – let’s ignore Vista-64’s requirement, let’s just talk about authenticode signing (which works down-level and not just on Vista, you DO realize this, right?) – is an excellent way to ensure the package is genuine and not modified.
Saying that’s not necessary or helpful, because you can download your drivers from a “reliable site” just demonstrates that you aren’t thinking through the problem before typing. Maybe nothing on YOUR computer is more valuable than a few naked pictures of your girlfriend, a collection of MP3s, and your Pr0n library… But some people use their computers for, like, real stuff. Do you realize that billions of dollars, fragile equipment, and even people’s lives can depend on proper software integrity?
Nah, screw that. Just download from a “reputable” source. Right…
I’m out of this discussion,
Peter
OSR
It is very good we can fortunately press F8 to at least disable Driver
Signing. Even test signing may come in handy if you do not yet have a real
certificate. Very good what you have done and are doing for the community,
thanks for that. Very good also you are pushing for the MKDF source to be
released, I hope we can get the filter manager source along as well and I
hope in the future you are also going to start a lobby against PatchGuard.
If OSR is not doing this, who else can do this ?
/Daniel
wrote in message news:xxxxx@ntdev…
>
> IF you’ve been following this whole Vista-64 driver signing requirement
> from the beginning, you’all already know that I’m not a big fan of
> the program. The community worked hard, and I personally worked VERY
> hard, to get the program modified so it had terms (like test signing, in
> fact) that we can live with.
>
Since the topic came back again …
Breaking such a public/private key is very probablistic. Deterministically
breaking it is very very tough !!!
What does it mean by very very tough? Any rough estimation or quantification
of these vague ( and relative ) words “very very tough” ?
Breaking of public/private key is by nature exponential. IIRC, it is
exponential with respect to number of bits.
And one of the (perhaps) most effective way to break it is brute force. When
you apply brute force, one of the first thing to look at is if the problem
is nicely partitionable. IIRC, it is.
So use parallel processing on sub-problems. But what in theory one can
achieve. There is a fundamental barrier. If an algorithm has O(n)
complexity, then parrallelism gives you O(log(n)). Without going into detail
analysis ( that anyone can find by seaching internet ) we can see the growth
path of the toughness of the algorithm for private/public key is much higher
than parallel hacking.
Since the key generation is based on large prime-number. And the computation
is based on some finite polynominal of some large prime. There are two areas
of ananlysis being persued: Nature and characteristics of the “Field of
finite polynomial” ( often called Galois field ); and finding the result of
(P == NP ) affirmitively.
The minute one proves P == NP, all the public/private key would be good
candidate to be trashed… Quite scary?
-pro
On 6/13/07, Paul Gardiner wrote:
>
> Daniel Terhell wrote:
> > What I think that is probably going to happen is that some hacker is
> > going to write some makecert utility which makes REAL fake certificates
> > and posts the utility to some warez group.
>
> That can’t be done… or at least not without the discovery of
> new mathematics. Its not just a case of reverse engineering.
> Indeed I believe the details of certificates is all in the public
> domain. The problem is, even with complete knowledge of the
> details, the calculations necessary to fake the signing
> with a private key, when you know only the corresponding
> public key, is beyond the capability of even the full
> resources of most governments computing resources,
> in reasonable time.
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> What I think that is probably going to happen is that some hacker is going
to write some makecert utility which makes REAL fake certificates and posts
the utility to some warez group.
As has been quickly pointed out by others, there is no known way to do this. Furthermore, given the astronomical number of top minds in the world working on exactly this issue (NP == P?) for many decades, it seems unlikely to ever happen.
Brute force is one approach - I remember reading a case study done by a university group not too long ago that determined a 1024-bit private key could be discovered but it cost ~$500K in hardware and you had to wait six months.
As some very skilled reverse engineer has pointed out on his site also
PatchGuard can be disabled.
Now, this is completely different! PatchGuard and the like simply *cannot* be guaranteed to work - only make things harder. I read the same articles on that site, and they state this right in the intro: kernel-mode code cannot protect itself from kernel-mode code.
Unless all other kernel-mode code is running on a virtualization system. This level of protection may be possible on Longhorn. Hmmm…
(Regarding displaying the driver probably at fault in BSOD):
Of course these measures do have some
implications such as in the case of a wrongly blamed driver or an OS bug but
these issues can be dealt with one way or another.
These implications are serious enough that what Microsoft does is after an automatic online BSOD analysis (Error Reporting), they won’t even tell you which driver it was unless that company has already issued an update.
Check out the “Windows Hang and Crash Dump Analysis” video by Russinovich (free download, and excellent video, BTW), where he describes different causes of BSODs, including many types of crashes that cause the *wrong* driver to be blamed by the automatic analysis.
-Stephen Cleary
wrote in message news:xxxxx@ntdev…
>
>
> and
>
>
>
> STOP stop stop stop stop. Be clueful or be quiet.
>
> First: MSFT doesn’t derive any revenue from driver signing. In fact, it’s
> a COST for them. Maybe it does generate revenue for the Verisigns of the
> world. But I rather doubt MSFT cares.
>
> Next: Know that few people here are trying to DEFEND the overall practice
> of requiring drivers to be signed to run on 64-bit Vista. I sure as
> hell am not defending it.
>
> IF you’ve been following this whole Vista-64 driver signing requirement
> from the beginning, you’all already know that I’m not a big fan of the
> program. The community worked hard, and I personally worked VERY hard, to
> get the program modified so it had terms (like test signing, in fact) that
> we can live with.
>
> Finally: THE most secure systems use non-network connected, quarantined,
> machines that only have software installed from CD that is obtained
> directly from the vendor. The images on these CDs are checksummed and the
> checksums are provided via a separate channel, so they can be
> independently validated become access. I know companies that do this.
>
> So, like, the people who run these systems are stupid? They should just
> download thier software from a “reputable source” and save themselves a
> lot of time, effort, and annoyance??
>
> Lacking the level of physical security I just described, insuring a driver
> package is signed – let’s ignore Vista-64’s requirement, let’s just talk
> about authenticode signing (which works down-level and not just on Vista,
> you DO realize this, right?) – is an excellent way to ensure the package
> is genuine and not modified.
>
> Saying that’s not necessary or helpful, because you can download your
> drivers from a “reliable site” just demonstrates that you aren’t thinking
> through the problem before typing. Maybe nothing on YOUR computer is more
> valuable than a few naked pictures of your girlfriend, a collection of
> MP3s, and your Pr0n library… But some people use their computers for,
> like, real stuff. Do you realize that billions of dollars, fragile
> equipment, and even people’s lives can depend on proper software
> integrity?
>
No, gee, I had no idea. I thought it was all about nekkid pictures. I
guess you told me, didn’t you?
> Nah, screw that. Just download from a “reputable” source. Right…
>
> I’m out of this discussion,
>
Thank you.
Actually, there are already trojans out there which are designed to steal
private keys associated with installed certificates. For example, see <
http://www.secureworks.com/research/threats/gozi/ >.
IMO, it’s only a matter of time before malware authors realize that stolen
VeriSign certs (harvested from compromised client systems) can be used to
``bless’’ their malware in a way that will require a great deal of time and
pain on behalf of Microsoft and the company/individual whose cert was stolen
to rectify (determining compromise date, revoking the cert, getting a new
cert, etc.) compared to relatively little work on behalf of malware authors
just grabbing another cert from another trojaned company box.
That is, of course, assuming malware doesn’t just exploit holes to bypass
kernel mode code signing entirely, or patch out the checks on disk and wait
for a reboot…
–
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
“Paul Gardiner” wrote in message news:xxxxx@ntdev…
> Daniel Terhell wrote:
>> What I think that is probably going to happen is that some hacker is
>> going to write some makecert utility which makes REAL fake certificates
>> and posts the utility to some warez group.
>
> That can’t be done… or at least not without the discovery of
> new mathematics. Its not just a case of reverse engineering.
> Indeed I believe the details of certificates is all in the public
> domain. The problem is, even with complete knowledge of the
> details, the calculations necessary to fake the signing
> with a private key, when you know only the corresponding
> public key, is beyond the capability of even the full
> resources of most governments computing resources,
> in reasonable time.
>
Prokash Sinha wrote:
Since the topic came back again …
Breaking such a public/private key is very probablistic.
Deterministically breaking it is very very tough !!!
> .
> .
> .
The minute one proves P == NP, all the public/private key would be good
candidate to be trashed… Quite scary?
But this is a big big problem. Anyone who could find a solution
to this one, is very unlikely to want to waste their time
sneaking unsigned drivers onto our computers. They’d probably
be too busy hiding from assassination attempts. Too much of
our society relies on this technology.
The answer of course is 42… 
----- Original Message -----
From: “Paul Gardiner”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, June 13, 2007 4:56 PM
Subject: Re: [ntdev] codesigning, it’s just a snack
> Prokash Sinha wrote:
>> Since the topic came back again …
>> Breaking such a public/private key is very probablistic.
>> Deterministically breaking it is very very tough !!!
>>
> > .
> > .
> > .
>> The minute one proves P == NP, all the public/private key would be good
>> candidate to be trashed… Quite scary?
>
> But this is a big big problem. Anyone who could find a solution
> to this one, is very unlikely to want to waste their time
> sneaking unsigned drivers onto our computers. They’d probably
> be too busy hiding from assassination attempts. Too much of
> our society relies on this technology.
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
Your stmt is true, very true, very very true …
I can’t agree more :-). And we can’t worry for unforeseen !
BTW, I just had to say what lies ahead …
-pro
Prokash Sinha wrote:
> Since the topic came back again …
>
> Breaking such a public/private key is very probablistic.
> Deterministically breaking it is very very tough !!!
>
> .
> .
> .
>
> The minute one proves P == NP, all the public/private key would be good
> candidate to be trashed… Quite scary?But this is a big big problem. Anyone who could find a solution
to this one, is very unlikely to want to waste their time
sneaking unsigned drivers onto our computers. They’d probably
be too busy hiding from assassination attempts. Too much of
our society relies on this technology.
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Steve Pratt wrote:
The answer of course is 42…
You should have kept that to yourself. They are after you now.
wrote in message news:xxxxx@ntdev…
> First: MSFT doesn’t derive any revenue from driver signing. In fact, it’s
> a COST for them. Maybe it does generate revenue for the Verisigns of the
> world. But I rather doubt MSFT cares.
Microsoft (read: the board & shareholders) of course does not care about
driver signing per se. What however they do care about, I am pretty sure,
are revenue streams. They apparently believe that the ability to revoke
their signature under third-party kernel drivers is one of the major
prerequisites for their Windows to be allowed playing DRM-protected content.
Driver signing may be a cost for them at the moment, but be sure they bear
these costs not because they care about us the poor customers subjected to
hacker attacks, or at least not primarily because of that. They anticipate
or are already getting huge revenue out of DRM, and that’s the reason for
the driver signing hassle.
One can easily sign both the installer and the driver binaries with
Authenticode. Beyond doubts, it’s a great thing for the customers as it
ensures the software is from a legitimate source. But Microsoft actually
stands on the way and actively prevents us from using Authenticode with
our drivers. Example? I open Device Manager, point to my device and check
the driver properties. Microsoft says there that my driver is not signed.
They are plainly lying. They knowingly prevent my customers from checking my
signature under the driver. Moreover, they display explicit warnings during
the installation saying that the driver is not signed. They are lying
again… If I open Windows Explorer and check the properties of my driver
file, the Explorer would display the proper signature with my company name
etc. Luckily, Explorer does not know yet that the file is a driver.
Now who can say after that that Microsoft cares about their customers
getting authentic software?! One can for sure say that Microsoft DOES care
that all the drivers are signed by Microsoft. One may ask, what would they
need that? Please, don’t tell the fairy tales about driver quality. Of
course this has nothing to do with that. If it had, Microsoft would display
a prompt saying that my driver is properly signed but just has not passed
the dubious WHQL tests. Then it would be up to the customer to decide who
they trust more - my company, the business of which does depend on the
quality of my drivers, or some WHQL. Would the next step be them signinig my
SSL certificates for my website to display propely in their browser, for
them to shut down my website at any time at their will?
Cheers
—
> Date: Sat, 23 Jun 2007 17:07:39 +0100
“Steve Pratt” wrote in message news:xxxxx@ntdev…
> The answer of course is 42…
>
How is it in the future, mate? What are the lotto numbers for the next week?
–
What’s wrong with patchguard? I think it’s great; it keeps individuals
with incredible kernel development skills such as yourself from f******
up other peoples systems…
Daniel Terhell wrote:
I hope in the future you are also going to start a lobby against
PatchGuard. If OSR is not doing this, who else can do this ?/Daniel
Somebody who is not ashamed to publicly post crap like this (this is your
code right ?) still needs to learn the most fundamental basics and refrain
from commenting on the coding skills of somebody else. Since you have made
it totally clear clear you have absolutely no clue what you are doing
yourself, any comment you may have about my coding skills is plain
ridiculous.
/Daniel
“MM” wrote …
-------------------------------------------------------------------------------
WCHAR NoteFile[3][200] = {
L"\EXPLORER.EXE",
L"\SYSTEM32\NOTEPAD.EXE", <-what I’m searching for
…
};
NTSTATUS
CouldItBeNotePad (
in PFLT_FILE_NAME_INFORMATION nameInfo,
out PBOOLEAN MayBe
)
{
UNICODE_STRING FileName;
NTSTATUS status;
int i;
for(i = 0; i < 3; i++)
{
FileName.Length = 0x0;
FileName.MaximumLength = sizeof(NoteFile[i]);
FileName.Buffer = NoteFile[i];
if (FsRtlIsNameInExpression( &FileName, &nameInfo->Name, TRUE, NULL
) == TRUE)
{
//never get here
DbgPrint(“A match was found %S\n”, NoteFile[i]);
*MayBe = TRUE;
}else{
//FsRtlIsNameInExpression always returns no match. Expression is UCase
*MayBe = FALSE;
DbgPrint(“%wZ \n”, FileName);
DbgPrint(“%wZ \n”, &nameInfo->Name);
}
}
return STATUS_SUCCESS;
}
-------------------------------------------------------
> What’s wrong with patchguard? I think it’s great; it keeps individuals
> with incredible kernel development skills such as yourself from f ****** up
> other peoples systems…
>
> Daniel Terhell wrote:
>
>> I hope in the future you are also going to start a lobby against
>> PatchGuard. If OSR is not doing this, who else can do this ?
>>
>> /Daniel
>>
>>
>