MantisBT - Doomseeker
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003673Doomseeker[All Projects] Bugpublic2019-06-28 08:522019-07-30 10:14
ReporterWubTheCaptain 
Assigned ToZalewa 
PrioritynoneSeverityminorReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version1.2 
Target VersionFixed in Version 
Summary0003673: Passwords may linger around in memory indefinitely
DescriptionThis is just a hunch based on quick source code grep for "password" (many results) and free()/memset()/explicit_bzero() (few to none), but I know Doomseeker handles some server passwords (which may or may not be found in the config file in plaintext anyway).

The exact scope of the issue is unclear to me, but one possibility could come into my mind: RCon client passwords, not from configuration. There may be many more. Do they linger around in the memory, never freed?
Steps To Reproduce
Additional InformationCategorizing as an epic, because I believe there will be many different parts to look at.
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2019-06-28 08:52WubTheCaptainNew Issue
2019-07-02 22:09ZalewaNote Added: 0020862
2019-07-03 07:22FilysteaNote Added: 0020863
2019-07-03 08:07WubTheCaptainAssigned To => Zalewa
2019-07-03 08:07WubTheCaptainStatusnew => acknowledged
2019-07-03 08:13WubTheCaptainNote Added: 0020864
2019-07-03 08:16WubTheCaptainCategoryEpic => Bug
2019-07-03 15:17ZalewaNote Added: 0020865
2019-07-03 20:50WubTheCaptainNote Added: 0020866
2019-07-03 21:22ZalewaNote Added: 0020867
2019-07-03 21:22ZalewaStatusacknowledged => resolved
2019-07-03 21:22ZalewaResolutionopen => won't fix
2019-07-30 10:14WubTheCaptainStatusresolved => closed

Notes
(0020862)
Zalewa   
2019-07-02 22:09   
The passwords definitely linger in memory. They are also sent over UDP in plain text to servers, appear in the command line, are stored in plain-text in config files, are probably kept by the games in memory as well, can be dumped to hard drive when OS swaps out RAM, can be dumped to hard drive when OS puts the system into hibernate mode, etc. Ask yourself how does the "send_password hunter2" ccmd work? We can scrub all the QStrings, hack all the QTextEdits and QTableWidgetItems, connect to the system's password vaults (Windows, by the way, has none) and create more maintenance hell with all of this and we won't be able to fix the problem.
(0020863)
Filystea   
2019-07-03 07:22   
Your next step will be adding encrypthed connecyion since they probably go via UDP as open txt? What is the purpose of this? Do you think someone will go through hell to obtain those to join a server? He can dos it. Easier and much harder to stop. Also bigger fun.
Probably if you take like any book on encrypth. There is always definition who you are protecting against / who is targeting you. Individual / company / country. I belive those kind of problems are out of scope when we talk about doom game server. Same goes with your problem of lingering in memory.
(0020864)
WubTheCaptain   
2019-07-03 08:13   
Quote from Zalewa
can be dumped to hard drive when OS swaps out RAM


I was thinking of this from the point of sharing coredumps in OP, although I did not consider they might be unencrypted in UDP too. Thus, when I said:

Quote from WubTheCaptain
The exact scope of the issue is unclear to me


I really meant things like the --rcon flag, which doesn't have an option to store passwords in configuration AFAIK. Those rcon passwords are in the memory indefinitely, not optionally requesting re-auth after a while.

Storing server passwords (login) in memory is a "feature", per se.
(0020865)
Zalewa   
2019-07-03 15:17   
From what I see at least for Zandronum the password is indeed sent securely by salting and hashing it, but the plugin itself keeps the plain-text in memory as long as the rcon is open.

Quote from WubTheCaptain
I really meant things like the --rcon flag, which doesn't have an option to store passwords in configuration AFAIK.


The entirety of the configuration is kept in the memory for the whole runtime of the program. But then again - what's the matter given that the passwords are available in the text files?

I will have to agree with Filistyn here that the level/scope of security threat that we're facing here doesn't justify spending time on extra scrubbing of RAM.
(0020866)
WubTheCaptain   
2019-07-03 20:50   
Quote from Zalewa
I will have to agree with Filistyn here that the level/scope of security threat that we're facing here


It wasn't categorized as a security issue...

Feel free to resolve this ticket in any way you like.
(0020867)
Zalewa   
2019-07-03 21:22   
If it isn't considered as a security issue, then I'm not sure what it is. Definitely not memleak either. Anyway, resolving as "won't fix" due to imbalance between required effort and benefits.