ILAsm should generate assemblies that are valid for binskim

ILAsm doesn't currently generated assemblies that will pass binskim. For example, https://github.com/microsoft/binskim/blob/main/docs/BinSkimRules.md#rule-ba2004enablesecuresourcecodehashing.

@JulieLeeMSFT

Tagging subscribers to this area: @JulieLeeMSFT
See info in area-owners.md if you want to be subscribed.

@amanasifkhalid

cc @amanasifkhalid, @AndyAyersMS.

Re: SHA-256 support, #85344 included some work to add it for non-Windows platforms, though the main blocker seemed to be finding an implementation(s) to take a dependency on so we don't have to roll our own.

JanK commented to contact the .NET Security Team.

The agreed upon plan was (quoting from the conversation with .NET Security Team):

Use the Windows API like I mentioned before.
OSX does have their own lib to do this, just will need to dig in to figure out exactly where/what it is. Will look at what we do for .NET Crypto.
For linux, we are going to use OpenSSL, but not take a hard dependency on it, meaning that if OpenSSL doesn't exist on the box, then they cannot use the deterministic flag. Warn if OpenSSL is not present.

OSX does have their own lib to do this, just will need to dig in to figure out exactly where/what it is

The implementation is here, but we have some abstraction on top of it. https://github.com/dotnet/runtime/blob/main/src/native/libs/System.Security.Cryptography.Native.Apple/pal_digest.c

Here is a more straightforward example of using Apple's APIs.

#include <CommonCrypto/CommonCrypto.h>
#include <CommonCrypto/CommonDigest.h>
#include <assert.h>
#include <stdio.h>

int main(int argc, char *argv[])
{
    // Apple documents these CommonCrypto functions as always return 1, so we will assert.
    CC_SHA256_CTX ctx = {{ 0 }};
    int ret;
    
    ret = CC_SHA256_Init(&ctx);
    assert(ret == 1);
    
    const char data1[] = "hello";
    const char data2[] = "world";
    
    // Example of doing two incremental updates to the digest context.
    ret = CC_SHA256_Update(&ctx, data1, 5);
    assert(ret == 1);
    
    ret = CC_SHA256_Update(&ctx, data2, 5);
    assert(ret == 1);
    
    unsigned char digest[CC_SHA256_DIGEST_LENGTH] = { 0 };
    ret = CC_SHA256_Final(digest, &ctx);
    assert(ret == 1);
    
    for (int i = 0; i < CC_SHA256_DIGEST_LENGTH; i++) {
        printf("%02x", digest[i]);
    }
    
    printf("%s", "\n");
}

For linux, we are going to use OpenSSL, but not take a hard dependency on it, meaning that if OpenSSL doesn't exist on the box, then they cannot use the deterministic flag. Warn if OpenSSL is not present.

Can we assume OpenSSL will be available on the build machine? Or would we want to make the SHA-256 implementation unavailable when building without OpenSSL installed? I'm hesitant about introducing a new dependency for building the repo.

Can we assume OpenSSL will be available on the build machine?

Generally, OpenSSL is a hard dependency for .NET on Linux. We abort when we cannot find it.

runtime/src/native/libs/System.Security.Cryptography.Native/opensslshim.c

Lines 175 to 181 in 10ee2b1

    
           void InitializeOpenSSLShim(void) 
        
           { 
        
               if (!OpenLibrary()) 
        
               { 
        
                   fprintf(stderr, "No usable version of libssl was found\n"); 
        
                   abort(); 
        
               }

It should be reasonable to expect OpenSSL to be present on any Linux system which .NET is expected to run on.

(libssl being one of the libraries part of OpenSSL, the other being libcrypto. We require both)

@jkotas

@jkotas did say

but not take a hard dependency on it, meaning that if OpenSSL doesn't exist on the box, then they cannot use the deterministic flag. Warn if OpenSSL is not present.

There might be some narrow circumstances where is it possible to do something with a .NET application without OpenSSL present, but build machines will generally have it, as building .NET requires it.

ilasm dependency on OpenSSL should have the same characteristics as the .NET runtime (System.Security managed APIs) dependency on OpenSSL:

For Microsoft (aka portable) builds, it should load whatever OpenSSL is installed on the system, it should not be hardcoded to one specific OpenSSL version
For source build builds, it should be directly bound against OpenSSL provided by the system

For System.Security managed APIs, this logic is implemented by native shim https://github.com/dotnet/runtime/tree/main/src/native/libs/System.Security.Cryptography.Native . You may want to reuse the implementation for ilasm since it is not exactly trivial. For example, instead of calling OpenSSL from ilasm directly, call the CryptoNative_ shim method from ilasm to perform the crypto operations and statically link the System.Security.Cryptography.Native shim into ilasm to deal with OpenSSL loading.

@Newrad0603

With #109091 merged in, ILAsm now emits PDB checksums hashed with SHA256. @Newrad0603 do you still need BinSkim compliance in the .NET Framework version of ILAsm?

@amanasifkhalid

@amanasifkhalid I was able to make a combination of tools and settings work to unblock my scenario for NetFx, so for now I no longer need support backported to NetFx ILAsm. Thanks for checking!

Glad to hear that! I don't think there's anything else needed here.

Navigation Menu

Repository navigation

ILAsm should generate assemblies that are valid for binskim #108627

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	void InitializeOpenSSLShim(void)
	{
	if (!OpenLibrary())
	{
	fprintf(stderr, "No usable version of libssl was found\n");
	abort();
	}

ILAsm should generate assemblies that are valid for binskim #108627

Description

Activity

dotnet-policy-service commented on Oct 7, 2024

JulieLeeMSFT commented on Oct 8, 2024

amanasifkhalid commented on Oct 8, 2024

JulieLeeMSFT commented on Oct 8, 2024

jkotas commented on Oct 8, 2024

vcsjones commented on Oct 11, 2024

amanasifkhalid commented on Oct 22, 2024

vcsjones commented on Oct 22, 2024

vcsjones commented on Oct 22, 2024

jkotas commented on Oct 22, 2024

amanasifkhalid commented on Jan 23, 2025

Newrad0603 commented on Jan 23, 2025

amanasifkhalid commented on Jan 23, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions