Title CVE-2020-14938: An issue was discovered in map.c
Priority release-blocker Status resolved
Assigned To fluzz Keywords
Linked issues CVE-2020-14939: An issue was discovered in savestruct_internal.c, Heap over-read in loading untrusted save game, Heap overflow in loading untrusted save game, Lua code execution in loading untrusted save game
View: 967, 952, 951, 953
Watchers fluzz

Submitted on 2020-06-26 06h42 by Snark, last changed by fluzz.

Author: Snark Date: 2020-06-26   06h42
This bug was reported against the Debian package but is an upstream issue:

It assumes lengths of data sets read from saved game files. It copies data from a file into a fixed-size heap-allocated buffer without size verification, leading to a heap-based buffer overflow.
Author: fluzz Date: 2020-06-29   13h49
This should be fixed, indeed.
Related issues : issue951, issue952 (how come we never commented those one ???)

But, however, if one tries to crash FDRPG with a malicious, I bet he will find thousands of way. Do we really have to protect against intentional corruptions ?
Author: Snark Date: 2020-08-02   12h01
Well, if user A corrupts data and gets user B to load it and can through this access anything unrelated to FDRPG, then yes, it's a security issue.
Author: jesusalva Date: 2020-08-02   15h56
Yes, but we do not have any support to 
transaction save files. I personally have 
a hard time when I need someone reporting 
a bug to upload their savegames (and that 
happens only when the file is already a 
"bad file", anyway).

People could try to get 100% completion 
savegames or have someone hack it; Both 
can be done more smartly by using the 
cheat menu or cheat level editor (it ought 
yo be more documented than savefiles, 
even), and are not something we encourage.

But then we have Murphy Law. If someone 
can do something the right way, OR by the 
wrong way, someone WILL do it the wrong 

I would not call this critical (and my 
initial proposal for a quick patch would 
be a banner  informing to never load a 
savegame from internet).

We also have that updating to fix this 
would change savefiles compatibility, so I 
think unlikely to a proper, real fix being 
deployed for 1.0 or anytime soon. But I'm 
not a coder.
Author: jesusalva Date: 2020-08-02   16h02
Also, there was something about safe and 
unsafe lua modes, I think that limiting 
lua to what we currently use would be the 
way to go but I know nothing about it. I 
might be talking nonsense here, this is 
why I split the post.
Author: fluzz Date: 2022-12-25   16h57
Fixed in commit e106cec2c
Lua sandboxing added
Date User Action Args
2022-12-25 16:57:36fluzzsetstatus: open -> resolved
messages: + msg3776
2021-11-13 22:33:14fluzzsetlinked: + Lua code execution in loading untrusted save game, CVE-2020-14939: An issue was discovered in savestruct_internal.c
2021-11-13 22:33:03fluzzlinkissue967 linked
2021-11-13 22:32:53fluzzlinkissue953 linked
2021-11-13 16:56:17fluzzsetlinked: + Heap over-read in loading untrusted save game
2021-11-13 16:56:09fluzzlinkissue952 linked
2021-11-13 16:55:47fluzzsetlinked: + Heap overflow in loading untrusted save game
2021-11-13 16:55:45fluzzlinkissue951 linked
2021-11-05 10:52:39fluzzsetpriority: important -> release-blocker
2020-08-02 16:02:46jesusalvasetmessages: + msg3702
2020-08-02 15:56:48jesusalvasetmessages: + msg3701
2020-08-02 12:01:44Snarksetmessages: + msg3699
2020-06-29 13:49:37fluzzsetassignedto: fluzz
messages: + msg3692
nosy: + fluzz
2020-06-26 06:42:08Snarkcreate