> -----Original Message-----
> From: Philip Wagenaar [mailto:p.wagenaar (at) accon (dot) nl [email concealed]]
> Sent: Friday, February 04, 2005 9:44 AM
> To: pen-test (at) securityfocus (dot) com [email concealed]
> As you know C#,VB.NET and Cobolt.NET etc etc all compile into the
> Common Runtime Language.
True, however keep in mind that every compiler has it's own set of idiosyncrasy, read: optimization that result in a way it creates CLR code. For example VB compiler is inserting nop opcodes sometimes probably for easier breakpoint insertion during debugging. A good example of how compilers differ might be how internally Win32 C++ compilers pass "this": most are using ecx register but not all.
> I am not aware of any big weaknesses in the CLR, but I would
> search for papers on the CLR instead of a specific .Net Language.
Start with reading something about .NET security model. As for CRL code you can use IDA Pro or ILDASM (which is free and comes with SDK) to look for problems at compiled code level. You can also look at places where unmanaged code is being called as it might be possible that while there is no vulnerability in particular CLR application by itself you might be able to exploit security problem in called DLL.
Exploiting .NET is similar to exploiting weaknesses in Java VMs; I would start looking at already described class of problems for most popular JVM implementations and try to do the same to .NET Framework.
Also keep in mind that .NET Framework Beta 2 is available to download.
> -----Original Message-----
> From: Philip Wagenaar [mailto:p.wagenaar (at) accon (dot) nl [email concealed]]
> Sent: Friday, February 04, 2005 9:44 AM
> To: pen-test (at) securityfocus (dot) com [email concealed]
> As you know C#,VB.NET and Cobolt.NET etc etc all compile into the
> Common Runtime Language.
True, however keep in mind that every compiler has it's own set of idiosyncrasy, read: optimization that result in a way it creates CLR code. For example VB compiler is inserting nop opcodes sometimes probably for easier breakpoint insertion during debugging. A good example of how compilers differ might be how internally Win32 C++ compilers pass "this": most are using ecx register but not all.
> I am not aware of any big weaknesses in the CLR, but I would
> search for papers on the CLR instead of a specific .Net Language.
Start with reading something about .NET security model. As for CRL code you can use IDA Pro or ILDASM (which is free and comes with SDK) to look for problems at compiled code level. You can also look at places where unmanaged code is being called as it might be possible that while there is no vulnerability in particular CLR application by itself you might be able to exploit security problem in called DLL.
Exploiting .NET is similar to exploiting weaknesses in Java VMs; I would start looking at already described class of problems for most popular JVM implementations and try to do the same to .NET Framework.
Also keep in mind that .NET Framework Beta 2 is available to download.
Best Regards,
Aleksander Czarnowski
AVET INS
[ reply ]