[PATCH] crypt32: Support CERT_QUERY_OBJECT_BLOB in CRYPT_QueryEmbeddedMessageObject().

[Paul Gofman]

On 3/29/22 14:05, Hans Leidekker wrote:
> On Mon, 2022-03-28 at 14:01 +0300, Paul Gofman wrote:
>> -    if (dwObjectType != CERT_QUERY_OBJECT_FILE)
>> +    if (dwObjectType == CERT_QUERY_OBJECT_BLOB)
>>       {
>> -        WARN("don't know what to do for type %ld embedded signed messages\n",
>> -         dwObjectType);
>> +        WCHAR temp_path[MAX_PATH], temp_name[MAX_PATH];
>> +        const CERT_BLOB *b = pvObject;
>> +
>> +        TRACE("cbData %lu, pbData %p.\n", b->cbData, b->pbData);
>> +
>> +        if (!GetTempPathW(MAX_PATH, temp_path) || !GetTempFileNameW(temp_path, L"blb", 0, temp_name))
>> +        {
>> +            ERR("Failed getting temp file name.\n");
>> +            return FALSE;
>> +        }
>> +        file = CreateFileW(temp_name, GENERIC_READ | GENERIC_WRITE, 0,
>> +                NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL | FILE_FLAG_DELETE_ON_CLOSE, NULL);
>> +        if (file == INVALID_HANDLE_VALUE)
>> +        {
>> +            ERR("Could not create temp file.\n");
>> +            SetLastError(ERROR_OUTOFMEMORY);
>> +            return FALSE;
> It would be nice to avoid creating a temporary file. Perhaps we could factor out
> a helper that operates on memory and rewrite CryptSIPRetrieveSubjectGuid() to
> use a file mapping?
>
>
Well, I thought of that, but the callchain currently ends in imagehlp 
which doesn't work with memory by design. As the test on testbot shows, 
the blob is supported starting from Win7, which, as I understand, 
coincides with crypt32 / cryptsp / advapi dependencies redesign on 
Windows. My understanding is that to solve this sensibly without 
introducing temporary files is to redesign that as well without relying 
on imagehlp, and maybe wintrust now should rely on crypt32 / cryptsp and 
not vice versa. So this is a question of course if localized fixes like 
this is a step in the right direction overall, but I don't currently see 
to make it the other way before such a broad redesign.