all groups > dotnet clr > august 2004 >
You're in the

dotnet clr

group:

Errr, Strong Named questions and Bug Report questions


Errr, Strong Named questions and Bug Report questions cwertman NO[at]SPAM webchamps.com
8/22/2004 6:09:26 PM
dotnet clr: I have 2 questions,

The first is, should I take a "StrongNamed" assembely and edit it with
a hex editor to change something in one of its resource files I need
changed, it barks about the Signature not matching.

No Suprise there,

BUT I have a different process whereby I can modify a StongNamed
assembely (not even my own) to me hearts content and there is NO
PROBLEM and the Signature remains intact (The ORIGINAL Signature) sn
-T returns the original value before AND after modification in this
manner.

Isnt that a HUGE Bug and/or security risk ? (To the point StrongNamed
ass are used to ensure security) ?????

If it is just me misunderstanding the nature of SN Assy ?

If this is a BUG/Security Issue, what is the "Proper" way through MS
Channels to report it and the correct time period for a fix to be
applied before releasing the issue to the world abroad.

The funny/sad part is this bug/feature is beneficial to me at the
moment, but the ability to add any code I want to anyones assembely
(MS Included) and have its SN Signature match what it did before it
was modified seems a bit spooky.

Please let me know how to proceed with this issue

Re: Errr, Strong Named questions and Bug Report questions Arne Janning
8/23/2004 3:37:55 AM

"WertmanTheMad" <cwertman@webchamps.com> schrieb
[quoted text, click to view]

sn -T only shows the public key token which is simply the last 8 bytes of a
SHA-1 hash over the public key.
Why should the public key change if you change something in an assembly in a
binary editor?

[quoted text, click to view]

I can't see a security bug. Try to load the strongly named assembly you
modified into the CLR and you'll get an error.

[quoted text, click to view]

Yes. Read this book:
http://www.awprofessional.com/title/0201734117

[quoted text, click to view]

Cheers

Arne Janning

Re: Errr, Strong Named questions and Bug Report questions cwertman NO[at]SPAM webchamps.com
8/23/2004 4:48:37 AM
[quoted text, click to view]

That is true if I load one modified with a hex ed, eveen 1 byte change
and it fails. BUT When I do it another way I can change as much as I
like and it SUCCEEDS,

Thats what I am trying to say shouldnt it FAIL after being modified ,
even heavily modified ?

I mean changing only 1 charachter in a resource file with a hex editor
it fails, if I do it the other way I stumbled upon (probably a result
of having no clue and not knowing better) it doen NOT Fail to load and
plays nice with all the other SN assy that are part of the application
(And are not written by me)

Re: Errr, Strong Named questions and Bug Report questions cwertman NO[at]SPAM webchamps.com
8/23/2004 11:49:22 AM
Thats what I am trying to say is it DOES LOAD !!!!!

It shouldnt but it DOES !

NOT By modifying it in a hex editor, but in a different way I have not
detailed here.

What I am saying is under no cirumstances should it LOAD after it has
been modified , correct ?

Well guess what it does.

Hence this posting

What do I do next ?


[quoted text, click to view]
Re: Errr, Strong Named questions and Bug Report questions Christian Heide Damm
8/23/2004 2:51:19 PM
sn.exe doesn't load the assembly for execution, so it's not the CLR that's
doing the loading, and hence no strong name verification is performed.

Same if you open your assembly in Notepad: no strong name verification.

But you can't load the assembly in to the CLR.

Christian

---

[quoted text, click to view]

Re: Errr, Strong Named questions and Bug Report questions Ben Schwehn
8/24/2004 11:29:38 AM
[quoted text, click to view]

You could post the example files somwhere on the web, because we don't
believe you ;)
You can file a bugreport at the MS Security Site
http://www.microsoft.com/technet/security/bulletin/alertus.aspx
or (this is really for whidbey only)
http://lab.msdn.microsoft.com/productfeedback/

--
Ben
Re: Errr, Strong Named questions and Bug Report questions Fabian Schmied
8/25/2004 11:20:39 AM
On 23 Aug 2004 11:49:22 -0700, WertmanTheMad <cwertman@webchamps.com>
[quoted text, click to view]

If you are absolutely sure you have found a way to circumvent strong
naming, could you maybe put an example online somewhere? Not how to
circumvent it, but a result, i.e. two .NET assemblies with different
contents but the same strong name.

Re: Errr, Strong Named questions and Bug Report questions Robert Jordan
8/26/2004 1:06:52 PM
Hi,

[quoted text, click to view]

it does load from where? from the GAC where the
original assembly still exists? :-)

[quoted text, click to view]

as long you don't tell us where (your) bug is, we won't belive you ;-)

[quoted text, click to view]

the big question is what and where are you loading from.
the another question is whether you disabled the StrongName
verification at all on your system.

[quoted text, click to view]

escalate it to BugTraq? ;-)

bye
Re: Errr, Strong Named questions and Bug Report questions Richard Grimes [MVP]
9/17/2004 5:20:36 PM
[quoted text, click to view]

When you sign an assembly the compiler takes a hash of the assembly and
signs it with the private key and then puts the signed hash and the public
key in the assembly. When .NET tries to load the assembly it will take a
hash of the assembly, extract the stored hash and decrypt it with the public
key and compare the two. If they are different it means that the assembly
has changed since it was signed. This is what you see.

[quoted text, click to view]

There's no surprise here too :-)

Now try to load that (tampered) signed assembly using the .NET loader.
You'll find that .NET will refuse.

[quoted text, click to view]

yes, I don't quite understand how you think that the signature gets into the
assembly.

[quoted text, click to view]

Report it here and someone will respond...

[quoted text, click to view]

You can change any assembly you like, but you will *not* be able to load
that assembly if it is signed and hence you will *not* be able to execute
code in it. If you change a signed assembly you are corrupting it, and
making it unusable.

Richard
--
..NET training, development, consulting and mentoring
my email evpuneqt@zicf.bet is encrypted with ROT13 (www.rot13.org)
sign up for my free .NET newsletter at
http://www.wd-mag.com/newsletters/

AddThis Social Bookmark Button