osquery/osquery

[powershell_events]: Buffer overrun due to signed / unsigned match

Closed this issue · 0 comments

Bug report

What operating system and version are you using?

Windows Server 2019 Datacenter

What version of osquery are you using?

osqueryi version 5.10.2-dirty
(Had to recompile 5.10.2 for symbols. )

What steps did you take to reproduce the issue?

Steps:

  • Install osquery on Windows Server 2019 / (Or Windows10)
  • Enable powershell script block logging
  • Create a config file with "feature_vector" entries like mentioned here
  • Run osqueryi.exe --disable_events=false --enable_powershell_events_subscriber --enable_windows_events_publisher --config_plugin=filesystem --config_path="C:\Program Files\osqery\osquery.conf"
  • Run a powershell script with special ascii characters. Example:
$o = "ÂÂÂÂÂ ÂÂÂÂÂÂÂÂÂÂ "
echo $o
  • This will cause buffer overrun of the buffer_freqs vector here
  • Since the script can be executed by any user, and buffer pointed above is used to WRITE to the pointed memory location, a specially crafted powershell script can be used to overrun buffer in osqueryd.exe execute code with the system process.

Vul

Compiler generates code such that chr value is stored into rax via movesx instruction. That makes it negative as soon as chr is above 128!
In the screenshot above, the movesx instruction stores 0xffffffffffffffc3 into rax when character being looked at is c3. This causes cosine similarity value to be stored at [rbx + rax * 8] which is way beyond the buffer_freqs vector and somewhere in memory. Can crash too.

A simpler way to observe this is to calculate cosine similarity of the script including special characters using another method (like python) and compare that with what above code outputs in ["cosine_similarity"] column.

What did you expect to see?

Expected to see rax in screenshot above store the value of character c3 or 129.

What did you see instead?

rax = 0xffffffffffffffc3