memory allocation of 11159284083750323767 bytes failedAborted (core dumped)
volfco opened this issue · 4 comments
I have this corrupted file, that I'm trying to load using the following code:
let map_loader = load_encrypted_file("./tgr/7.bin", 0, "mykeyhere");
Loading this file causes the following error:
memory allocation of 11159284083750323767 bytes failedAborted (core dumped)
It seems to me this should throw an error and not cause a core dump.
EDIT. It looks any binary file will cause this. I used dd if=/dev/urandom of=7.bin bs=1024 count=3 to make one, and it core dumped like above
Edit: The issue is fixed in version 0.4.1
I agree, this should not happen. I'll fix it immediately.
I haven't really considered security when designing savefile. The file you are loading is considered 'trusted'. In this particular case, there is no undefined behaviour in the strict sence, since aborting is considered 'safe'. But is is very inconvenient, and it could be a security issue if an attacker has the ability to inject corrupt encrypted files.
Since I'm using AES GCM for the encryption, this shouldn't really happen. All data actually parsed by savefile must have been created by someone with knowledge of the password.
The problem here is that the block-length itself isn't encrypted, so an attacker can just arrange for the block length to be arbitrarily long and thus crash the program.
The fix is simple in theory, since we can know what the maximum valid block length can be.
A fix is coming up.
Ok, just published 0.4.1, which should fix this.
So in summary, the problem was that block lengths encoded in files were not validated. This meant that an attacker controlling the crypto stream, could cause denial of service (through memory exhaustion).
The fix is to statically verify the block length to at most 100kB. An attacker can waste 100kB, but not more, since after those 100kB come an AES GCM tag, and an attacker without access to the crypto key won't be able to supply a tag that is accepted by the reader.
Note, all of this hinges on using very strong passwords, and keeping these secret. Since there is no salt or strong password hash, the passwords should basically be 32-64 character cryptographically random strings for highest security.