69 lines
2.6 KiB
Markdown
69 lines
2.6 KiB
Markdown
|
|
## Vulnerabilities in original engine
|
|
|
|
This document points out vulnerabilities in original game engine and describes vectors of attack
|
|
to exploit them.
|
|
|
|
This document is for educational purposes only to raise awareness (about learning how dangerous it is to run public Starbound
|
|
server on original engine), and pursues no goal of harming users of original engine.
|
|
|
|
Experienced blackhats already could take sources and dig these invulnerabilities themselves,
|
|
since most of them are not buried anywhere deep in code.
|
|
|
|
-----------
|
|
|
|
### EntityDestroyPacket vulnerability
|
|
|
|
When client sends EntityCreatePacket to WorldServer, it checks whenever received `entityId` is within
|
|
allowed range (range of IDs allocated specifically for that client). Same happens on EntityUpdateSetPacket.
|
|
|
|
However, someone forgot to put the same check when receiving EntityDestroyPacket, hence
|
|
any client can remove ANY other entity inside world, including other PlayerEntitys'.
|
|
|
|
On side note, original client makes sure it sends EntityDestroyPacket only for entities it owns.
|
|
|
|
This attack require modified game client.
|
|
|
|
-----------
|
|
|
|
### Zip bomb in PacketSocket
|
|
|
|
When packets are received on network socket, they are checked for not exceeding 16 MiB,
|
|
by reading packet length header. However, when receiving compressed packets,
|
|
only compressed size is checked against 16 MiB limit, and
|
|
they are uncompressed in one shot, without limiting uncompressed size.
|
|
|
|
This vulnerability allows to make server quickly run out of memory by forging zip-bomb packet.
|
|
|
|
This attack require modified game client.
|
|
|
|
-----------
|
|
|
|
### Client's ShipWorld size
|
|
|
|
When joining server, client sends contents of `.shipworld` in form of chunk map
|
|
(Map with bytearray keys and bytearray values, which represent data stored inside BTreeDB).
|
|
|
|
Server instances WorldServer with provided world chunks. The vulnerability lies within world's size.
|
|
|
|
Original engine world's chunk map is always stored as tight 2D array of chunk (sector) pointers,
|
|
and pointer array is always fully preallocated when world is instanced.
|
|
|
|
So client can forge custom shipworld, with 2^31 x 2^31 dimensions, which will instantly cause
|
|
server to consume at least 128 GiB of RAM when client connects.
|
|
|
|
This attack does not require modified game client.
|
|
|
|
-----------
|
|
|
|
## Exploits in original engine
|
|
|
|
These kind of bugs don't directly compromise security of server, but may degrade its performance.
|
|
|
|
-----------
|
|
|
|
### Client context window size
|
|
|
|
Window size as reported by client is not checked for insane values, allowing to greatly slowdown the server if client
|
|
is residing in large world, and reporting to be tracking entire world.
|