merces / libpe Goto Github PK

Currently libpe API supports "sections", "headers", "Directories". We need to add support for other properties of the PEV like "hashes", "Imports", "exports", "resources", "relocations", "entrophy".

Extra null pointer checks are not needed in the function "pe_unload".

When examining EFI PE files, it is very useful to calculate the Authenticode hash, which is used by the UEFI firmware to record measurements into the TPM. Currently pehash does not produce this hash.

More info: https://msdn.microsoft.com/en-us/library/windows/desktop/ms680547(v=vs.85).aspx#appendix_a__calculating_authenticode_pe_image_hash

Hello guys.

I have found a bug on pe_exports function from exports.c which allows me to exploit readpe.exe program from pev 0.81 (last release).

The issue occurs on the following lines:

The array offsets_to_Names is dynamically allocated on the stack using exp->NumberOfFunctions as its size (line 104). However, the loop starting at line 111 uses exp->NumberOfNames to iterate over it and set values at line 132. Therefore, this snippet assumes that exp->NumberOfFunctions is greater than ordinal at each iteration.

That condition may be followed by compilers, but not by hackers. What happens if I craft a PE file with ordinal greater than or equal to exp->NumberOfFunctions? Depending on the values, I am able to overwrite the return address of pe_exports function. On Windows 7 and Windows Server 2008 (systems on which I could produce higher impact), I may even use a ROP chain to get an arbitrary code execution.

I have recorded a PoC video to proof the exploitability of the bug on readpe.exe: https://drive.google.com/file/d/1zBH9ykgmHlnWQEBDIxwrYG8CTrHtUf26/view?usp=sharing.

If you guys need any more details about the bug, I am at your disposal!

Valgrind shows memory leaks at 5 places in file:

==1369== 17 bytes in 1 blocks are definitely lost in loss record 1 of 27
==1369==    at 0x4C2DBCD: malloc (vg_replace_malloc.c:299)
==1369==    by 0x586E799: strdup (strdup.c:42)
==1369==    by 0x4E503AB: get_hashes (in /usr/local/lib/libpe.so.1.0)
==1369==    by 0x4E505D2: get_headers_dos_hash (in /usr/local/lib/libpe.so.1.0)
==1369==    by 0x4E5078F: get_headers_hash (in /usr/local/lib/libpe.so.1.0)
==1369==    by 0x109106: main (in /home/boddu/github/boddumanohar/exe-check)
==1369==
==1369== 18 bytes in 1 blocks are definitely lost in loss record 2 of 27
==1369==    at 0x4C2DBCD: malloc (vg_replace_malloc.c:299)
==1369==    by 0x586E799: strdup (strdup.c:42)
==1369==    by 0x4E503AB: get_hashes (in /usr/local/lib/libpe.so.1.0)
==1369==    by 0x4E50646: get_headers_coff_hash (in /usr/local/lib/libpe.so.1.0)
==1369==    by 0x4E508BC: get_headers_hash (in /usr/local/lib/libpe.so.1.0)
==1369==    by 0x109106: main (in /home/boddu/github/boddumanohar/exe-check)
==1369==
==1369== 25 bytes in 1 blocks are definitely lost in loss record 3 of 27
==1369==    at 0x4C2DBCD: malloc (vg_replace_malloc.c:299)
==1369==    by 0x586E799: strdup (strdup.c:42)
==1369==    by 0x4E503AB: get_hashes (in /usr/local/lib/libpe.so.1.0)
==1369==    by 0x4E506E0: get_headers_optional_hash (in /usr/local/lib/libpe.so.1.0)
==1369==    by 0x4E5082D: get_headers_hash (in /usr/local/lib/libpe.so.1.0)
==1369==    by 0x109106: main (in /home/boddu/github/boddumanohar/exe-check)
==1369==
==1369== 51 bytes in 8 blocks are definitely lost in loss record 5 of 27
==1369==    at 0x4C2DBCD: malloc (vg_replace_malloc.c:299)
==1369==    by 0x586E799: strdup (strdup.c:42)
==1369==    by 0x4E503AB: get_hashes (in /usr/local/lib/libpe.so.1.0)
==1369==    by 0x4E50B17: get_sections_hash (in /usr/local/lib/libpe.so.1.0)
==1369==    by 0x1092BB: main (in /home/boddu/github/boddumanohar/exe-check)

==1369== 129,173 (24 direct, 129,149 indirect) bytes in 1 blocks are definitely lost in loss record 27 of 27
==1369==    at 0x4C2DBCD: malloc (vg_replace_malloc.c:299)
==1369==    by 0x4E511DA: imphash_load_imported_functions (in /usr/local/lib/libpe.so.1.0)
==1369==    by 0x4E517E7: pe_imphash (in /usr/local/lib/libpe.so.1.0)
==1369==    by 0x109E64: main (in /home/boddu/github/boddumanohar/exe-check)
==1369==

The first 4 errror are due to crypto library we are using.
EVP_cleanup(); which we used before exiting calc_hash will only clean the used memory partially.

And the last one is because, we are not freeing the linked list (where head variable is the head of the linked list). Each node is added after each call to imphash_load_imported_functions function.

Hello guys,

I didn't understand the reason for this 'if'. I think it will match with PE files having only one section in which the field VirtualAddress is greater than rva. In this case, is it rva pointing to some header? Wouldn't be better return the difference between rva and imagebase?

Cheers!

Dear developer. The fix in 5737a97 was just brought to my attention, and it made me wonder if the issue can cause a security issue with specially created PE binaries. Is the fix security related, and if so, is there a CVE assigned to the issue?

I the pull #14 I did not move code of pesec.c

What I am assuming is that we going to move everything to libpe and make PEV use libpe as a dependency completely. If I am correct, we should move pesec.c code to libpe ( I will make of list of things that are yet to be moved) so that we can release the next version which completely uses libpe. This will make the code of PEV a lot cleaner.

Hi,

I am trying to package pev for Alpine Linux but the tarball is missing libpe.

Would it be possible to make a tagged release matching the latest release of pev?

Found this problem when i was developing with libpe,

I make a quickfix by changing installation path of the .so to /usr/lib/ instead /usr/local/lib in Makefile

prefix = /usr

Don't know if this will break other projects too. but a symlink will be useful too.

Since I am new to C projects, I am having a doubt when should I use #pragma pack. In all the header files we have used #pragma pack(push, <somenumber> and #pragma pack(pop)

I've read this blog https://msdn.microsoft.com/en-us/library/2e70t5y1.aspx even still my doubt is not clarified. Can you please explain in simple terms

1. When should I use this?
2. What if I dont use this?

Thanks,
Manohar.

From the comments:
// We want to use NumberOfFunctions for looping as it's the total number of functions/symbols
// exported by the module. On the other hand, NumberOfNames is the number of
// functions/symbols exported by name only.

exports->functions_count = exp->NumberOfFunctions;
const size_t functions_size = exp->NumberOfFunctions * sizeof(pe_exported_function_t);
exports->functions = malloc(functions_size);
if (exports->functions == NULL) {
	exports->err = LIBPE_E_ALLOCATION_FAILURE;
	return exports;
}
memset(exports->functions, 0, functions_size);

for (uint32_t i=0; i < exp->NumberOfFunctions; i++) {

This is slightly wrong. NumberOfNames can differ from NumberOfFunctions, either smaller or larger. You really have three things to deal with:
NumberOfFunctions - All Symbols exported
NumberOfNames - All names that match up to symbols
Function exported by ordinal only

For this last one, you need to take all functions, and subtract out the ones that got names. The ones that are left are the ones exported by ordinal only.

Also, the 'ordinal' is actually a 'hint', which is the actual offset into the first array, meaning it is zero based. Any usage of ordinals is purely on the input side, meaning, if a user calls get pointer and uses an ordinal, the ordinal base is subtracted to give you the 0-index. The named things don't actually do this calculation, they just use the offset directly (counter to MS documentation).

when I run the demo code, At the end I see the output of imphash value as

imphash: (null)

Write documentation!