PrBoom-plus is a Doom source port based on PrBoom (which itself is based on other projects). It supports Windows, Mac, Linux and BSD systems. As I’m a Doom fan by myself I decided to get PrBoom-plus and analyze it from security perspective.
Compilation with ASAN
I started with downloading the project from repository and preparing for compilation with ASAN.
According to INSTALL file I installed required packages.
Also, I added useful compilator flags, because it appeared that CFLAGS environment variable placed additional parameters in invalid order, making them useless.
After such preparation I was able to compile the project with ASAN.
After compilation, there was the last step required before running the game. PrBoom-Plus is just an engine, so it requires game data to run. I was mostly interested in multiplayer part, so I chose FreeDM, the multiplayer part of Freedoom project.
First run and crash
When everything was ready, it was possible to run the server and the client.
The first crash occured immediately, just by running the client.
Analyzing first crash
The client crashes on reading outisde a buffer in ChecksumPacket function in src/SDL/i_network.c:221.
It seemed that len variable has greater values than size of p buffer. This function was called from I_GetPacket in src/SDL/i_network.c:243.
Here the problem starts to become visible. Value from udp_packet->len is assigned to a len variable. Then, there’s a check (line 234) to ensure les is not greater than buflen (buffer’s size). If it is, les is reduced to value of buflen. Invocation of memcpy properly uses len variable, so no data will be written outside the buffer. However, invocation of ChecksumPacket uses udp_packet->len which may be greater than buffer’s size, finally leading to reading outside it.
To fix this bug, I passed len variable, the same way as it is done with memcpy.
After recompilation, the game started to work (the game requires two players to start, the client’s command should be ran twice)
I wanted to fuzz network part of the project. The idea was very simple - collect some network data samples, modify and send. Implementation was even more simplier and naive. I began with collecting data. I ran Wireshark, played the game for a while (2 player game by myself, it was quite strange) and saved the traffic. Then downloaded and built radamsa and installed scapy.
Scapy script responsible for parsing data, modifying with radamsa (I know it’s inefficient) and resend. To fuzz the client instead of the server, UDP port should be changed from 5030 to 1024. The first line in s function calculates a checksum which validated after being received.
Note: for some reason packets sent between the client and the server from the same machine didn’t reach their destination. A workaround was to clone my virtual machine and run fuzzing from it.
After a while two crashes were found, the first one in the server, and the second one in the client. However, they are related and share similar bug.
Server crash 1
Minimal payload to crash \xb6\x05\x01\x01\x56\x33\x27\xff\x00.
The program tried to write 10991 bytes to a buffer with 10000 bytes on a heap in I_SendPacketTo in src/SDL/i_network.c:261.
From this I assummed that len variable was greater than length of udp_packet->data, so I started digging.
UDP packet has fixed size of 10000 bytes. A packet from which data was copied is allocated in main function in src/d_server.c:688.
tics variable was the only variable partially controlled from network input, so I followed how it was set.
remoteticto is set here:
This array is signed int type,
but a packet received over network is parsed to packet_header_t structure with unsigned tic (0xff273356 from the payload). When tic is assigned to the array (line 565), integer overflow occurs and it becomes a negative value (-14208170). In the result, in line 684, this whole value is zeroed. lowtic is the only variable on which tics depends (line 685).
lowtic is taken from remoteticfrom which grows itself as the game is started and players connected. In practice waiting for less than 20 seconds was enough to get lowtic greater than 525, which resulted in the allocated buffer bigger than 10000 bytes and finally in heap buffer overflow.
Client crash 1
Minimal payload to crash: \xb4\x05\x00\x00\x56\x33\x27\xff
and the result:
A function I_SendPacket in src/SDL/i_network.c:254 copies more bytes than allocated fixed 10000 bytes in UDP packet.
I looked how size_t len is calculated in src/d_client.c and this problem looked similar to the previous one.
remotesend is a signed integer, but tic in packet is unsigned, so integer overflow occurs and 0xff273356 from the payload becomes a negative value. In line 353 remotesend is zeroed, so sendtics depends only on maketic. This variable grows itself as the game is on, and when it reaches 1249 (in practice it was less than a minute) the allocated buffer is bigger than fixed 10000 bytes and heap buffer overflow occurs.
The first crash was found just after starting the game, the next two after very quick and naive fuzzing. I don’t consider this topic as closed, but I reported my findings and I’m moving to looking for another vulnerabilities using various approaches.
According to art. 13 of the General Regulation on the Protection of Personal Data of 27 April 2016 (Official Journal EU L 119 of 04.05.2016) I inform that:
1) the administrator of your personal data is Logicaltrust Sp. z o.o. Sp. k. - al. Aleksandra Brücknera 25-43, 51-411 Wrocław,
2) contact with the Personal Data Administrator - firstname.lastname@example.org,
3) Your personal data will be processed for marketing purposes on the basis of Art. 6(1)(a) of the general regulation on the protection of personal data of April 27, 2016..
4) Your personal data will be stored until you withdraw your consent
5) You have the right to request from the administrator access to personal data, the right to rectify their removal or limit processing, the right to withdraw consent and the right to transfer data
6) You have the right to lodge a complaint with the supervisory authority
7) Your data will be processed in an automated manner, including in the form of profiling. Automated decision-making will take place on the principles set out in the regulations (options: subscription, competition, etc.) and the consequence of such processing will be receiving selected marketing information
8) providing personal data is voluntary, however failure to provide data may result in the inability to participate in the newsletter subscription, participate in contests, receive marketing offers, participate in surveys
At the same time, pursuant to Art.6(1)(a) of the general regulation on the protection of personal data of 27 April 2016, I agree to the processing of my personal data for the purpose of subscribing to the newsletter, participation in competitions, receiving marketing offers, participation in surveys