Hello,
Recently I was shocked to notice sabnzbd does not encrypt username and password information within the .ini configuration file.
This alone is alarming, however...
Ubuntu likes to send crash report data. If sabnzbd crashes Ubunutu will also send the .ini file.
Just thought people should know.
Please fix.
Security.
Forum rules
Help us help you:
Help us help you:
- Are you using the latest stable version of SABnzbd? Downloads page.
- Tell us what system you run SABnzbd on.
- Adhere to the forum rules.
- Do you experience problems during downloading?
Check your connection in Status and Interface settings window.
Use Test Server in Config > Servers.
We will probably ask you to do a test using only basic settings. - Do you experience problems during repair or unpacking?
Enable +Debug logging in the Status and Interface settings window and share the relevant parts of the log here using [ code ] sections.
Re: Security.
I'm wondering:
1) What is your output of "ls -al ~/.." ?
2) You probably have all types of personal/private documents, pictures and videos on your system. How are the protected / encrypted?
1) What is your output of "ls -al ~/.." ?
2) You probably have all types of personal/private documents, pictures and videos on your system. How are the protected / encrypted?
-
RootCookie
- Newbie
- Posts: 3
- Joined: January 5th, 2014, 5:07 pm
Re: Security.
Code: Select all
rootcookie@RootCookie ~ $ ls -al ~/..
total 44
drwxr-xr-x 5 root root 4096 Oct 13 21:41 .
drwxr-xr-x 23 root root 4096 Jan 5 17:21 ..
drwxr-xr-x 3 root root 4096 Nov 21 13:07 .ecryptfs
drwx------ 2 root root 16384 Nov 21 13:02 lost+found
drwx------ 35 rootcookie rootcookie 16384 Jan 5 23:06 rootcookiePasswords should never be written down. This much I know.
Re: Security.
Sure, don't put them on a post-it attached to your monitor. But unless you want to re-enter all your usenet-related credentials every time, passwords will have to be stored by programs somehow. As soon as that were to be done encrypted, they would have to be decrypted for the program to be able to authenticate to servers, indexers and what not. Note that just obfuscating stuff in the ini doesn't work: it would be trivial to undo that, using sab's own open source code as a perfect reference implementation. In the end you'd have to interactively provide some kind of master key over and over again, a major hassle for very little benefit.RootCookie wrote:My home directory is encrypted, others may not, this protect me against theft but not against the crash report or people who have access to the computer.
Passwords should never be written down. This much I know.
You would then have to stand guard as long as the clear text password is stored in ram whilst downloading, and securely store your entire computer system afterwards to prevent someone from tampering with the hardware. In real life, a bit of common sense goes a long way (home dir encryption for theft, secure file permissions to keep other users out, disabling or at least not blindly hitting 'ok' on crash reports, etc...). I don't think those automatically generated bug reports on ubuntu are ever sent without the user's permission, and iirc those based on crash reports are marked private by default on launchpad.
Re: Security.
What is the reason the sabnzbd.ini file is included in the crash report?
Is there a way to disable this?
I do share RootCookie's concern about it being included.
At the same time, where would I store a secret key, without it also being included in a crash report?
Is there a way to disable this?
I do share RootCookie's concern about it being included.
At the same time, where would I store a secret key, without it also being included in a crash report?
Re: Security.
That's the OP's *assumption*shypike wrote:What is the reason the sabnzbd.ini file is included in the crash report?
Is there a way to disable this?
I do share RootCookie's concern about it being included.
At the same time, where would I store a secret key, without it also being included in a crash report?
Yes; Ubuntu asks before sending any info
If it is true
Exactly
-
RootCookie
- Newbie
- Posts: 3
- Joined: January 5th, 2014, 5:07 pm
Re: Security.
Thanks for the reply.
Yes, Ubunutu asks before sending the .ini
It asks to send the .ini after a crash because it noticed it was a modifed version (That is what is says), I guess from the origional.
It isnt a matter of blindly clicking, its not being well informed about the contents of the .ini
I used to use Newsbin, I'm pretty sure they encrypted sensative information in their settings file.
Yes, Ubunutu asks before sending the .ini
It asks to send the .ini after a crash because it noticed it was a modifed version (That is what is says), I guess from the origional.
It isnt a matter of blindly clicking, its not being well informed about the contents of the .ini
I used to use Newsbin, I'm pretty sure they encrypted sensative information in their settings file.
Re: Security.
I really want to see proof of sabnzbd.ini being part of these reports, not just for the obvious security/privacy concern but also simply because all of ~/.sabnzbd isn't part of any package. From the perspective of the os, it's just a file created by the user; there simply isn't an "original". Some packages even install files in /usr/share/apport/package-hooks/ to include (sanitized) config files in reports, which suggests those wouldn't have been there by default.RootCookie wrote:It asks to send the .ini after a crash because it noticed it was a modifed version (That is what is says), I guess from the origional.
For sab, I wouldn't expect to find configuration data beyond maybe /etc/default/sabnzbdplus (init script config). The bug at https://bugs.launchpad.net/ubuntu/+sour ... ug/1077305 is reported using apport but doesn't include a sabnzbd.ini. There's also a number of error reports at https://errors.ubuntu.com/?package=sabn ... 2014-01-06 but their content is off limits to me.
RootCookie: can you check if you still have that crash report sitting in /var/crash/ so we can finally know what's in there?