Submitted on 2020-06-26 06h42 by Snark, last changed by fluzz.
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.
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 ?
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.
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.
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.