Zandronum Chat on our Discord Server Get the latest version: 3.1
Source Code
My View | View Issues | Change Log | Roadmap | Doomseeker Issue Support Ranking | Rules | My Account
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
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?
Additional InformationCategorizing as an epic, because I believe there will be many different parts to look at.
Attached Files

- Relationships

-  Notes
User avatar (0020862)
Zalewa (developer)
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.
User avatar (0020863)
Filystea (reporter)
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.
User avatar (0020864)
WubTheCaptain (reporter)
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.
User avatar (0020865)
Zalewa (developer)
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.
User avatar (0020866)
WubTheCaptain (reporter)
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.
User avatar (0020867)
Zalewa (developer)
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.

Issue Community Support
This issue is already marked as resolved.
If you feel that is not the case, please reopen it and explain why.
Supporters: No one explicitly supports this issue yet.
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2019-06-28 08:52 WubTheCaptain New Issue
2019-07-02 22:09 Zalewa Note Added: 0020862
2019-07-03 07:22 Filystea Note Added: 0020863
2019-07-03 08:07 WubTheCaptain Assigned To => Zalewa
2019-07-03 08:07 WubTheCaptain Status new => acknowledged
2019-07-03 08:13 WubTheCaptain Note Added: 0020864
2019-07-03 08:16 WubTheCaptain Category Epic => Bug
2019-07-03 15:17 Zalewa Note Added: 0020865
2019-07-03 20:50 WubTheCaptain Note Added: 0020866
2019-07-03 21:22 Zalewa Note Added: 0020867
2019-07-03 21:22 Zalewa Status acknowledged => resolved
2019-07-03 21:22 Zalewa Resolution open => won't fix
2019-07-30 10:14 WubTheCaptain Status resolved => closed




Questions or other issues? Contact Us.

Links

Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker