[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.
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