Bug 20611 - Joinskript-Passwort in Prozessliste sichtbar
Joinskript-Passwort in Prozessliste sichtbar
Status: RESOLVED DUPLICATE of bug 46842
Product: UCS
Classification: Unclassified
Component: Join (univention-join)
UCS 2.4
Other Linux
: P2 normal (vote)
: UCS 3.2-x
Assigned To: Bugzilla Mailingliste
:
: 22059 (view as bug list)
Depends on:
Blocks: 41105
  Show dependency treegraph
 
Reported: 2010-11-05 11:20 CET by Sönke Schwardt-Krummrich
Modified: 2019-02-18 17:00 CET (History)
7 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sönke Schwardt-Krummrich univentionstaff 2010-11-05 11:20:10 CET
Derzeit ist das an Joinskripte übergebene Passwort in der Prozessliste sichtbar.

Hier sollte (ggf. in Verbindung mit Bug 20610) geprüft werden, wie dies verhindert werden kann.
Comment 1 Philipp Hahn univentionstaff 2012-09-18 08:28:33 CEST
*** Bug 22059 has been marked as a duplicate of this bug. ***
Comment 2 Janek Walkenhorst univentionstaff 2013-07-03 17:03:12 CEST
A program can (try to be fast to) hide the information in /proc/$$/cmdline by overwriting it, but this always leaves a short time where the information can be obtained.

Therefore sensitive information cannot be passed securely via command line parameters.


Additionally (ba)sh does not seem to offer the functionality of changing /proc/$$/cmdline.


Thus other options for passing the password are required to remove this problem:

One possibility is writing the information to a file and passing the path of the file via command line.

Another possibility is passing the information via the /proc/$$/environ.

Further possibilities are passing the information via file handles (stdin, pipe on fd 3) or sockets.


Simplicity:
environ
tempfile
pipe

Security:
pipe (can only accessed once)
environ (can be accessed multiple times, by subprocesses if not unset)
tempfile (can be accessed multiple times, by every process of that user)
Comment 3 Sönke Schwardt-Krummrich univentionstaff 2013-07-04 08:43:53 CEST
(In reply to Janek Walkenhorst from comment #2)
> Security:
[...]
> environ (can be accessed multiple times, by subprocesses if not unset)
> tempfile (can be accessed multiple times, by every process of that user)

Since joinscripts are usually called as user "root", all files of the whole system are "vulnerable". So a subprocess with root privileges may even read the environment of its parent process. Unsetting an environment variable does not update /proc/$$/environ. So in this case, I would consider "environ" even more unsafe than "tempfile", since files may be deleted before the subprocess is called.
Comment 4 Janek Walkenhorst univentionstaff 2013-07-04 14:25:27 CEST
(In reply to Sönke Schwardt-Krummrich from comment #3)
> (In reply to Janek Walkenhorst from comment #2)
> > Security:
> [...]
> > environ (can be accessed multiple times, by subprocesses if not unset)
> > tempfile (can be accessed multiple times, by every process of that user)
> 
> Since joinscripts are usually called as user "root", all files of the whole
> system are "vulnerable".
Different issue.

> So a subprocess with root privileges may even read
> the environment of its parent process.
This is not limited to root - every process of a user can do everything with every other process running as the same user.

> Unsetting an environment variable does not update /proc/$$/environ.
It can be hidden the same way /proc/$$/cmdline can.
Like with cmdline, Bash does not provide that functionality either.

> So in this case, I would consider
> "environ" even more unsafe than "tempfile", since files may be deleted
> before the subprocess is called.
(As discussed) "environ" may be a security problem when incorrectly starting processes via su, compared to "tempfile".


(As discussed) "environ" is more probably more complicated to use than "tempfile".
Comment 5 Moritz Muehlenhoff univentionstaff 2013-07-04 14:35:17 CEST
Or we could fix it in general on the kernel level in procfs with hidepid=2:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0499680a42

This was introduced in 3.4 (but it's even available in 3.1-1 since it was backported in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669028)
Comment 6 Florian Best univentionstaff 2013-07-04 14:48:47 CEST
(In reply to Moritz Muehlenhoff from comment #5)
> Or we could fix it in general on the kernel level in procfs with hidepid=2:
> 
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/
> ?id=0499680a42
> 
> This was introduced in 3.4 (but it's even available in 3.1-1 since it was
> backported in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669028)
Nevertheless it would be visible in the top module.
Comment 7 Stefan Gohmann univentionstaff 2013-08-07 08:59:06 CEST
I don't think this issue is a release blocker since the login as a normal user is not allowed.
Comment 8 Stefan Gohmann univentionstaff 2013-09-04 12:25:18 CEST
Not for UCS 3.2.
Comment 9 Philipp Hahn univentionstaff 2013-11-27 10:30:35 CET
This was again seen by a customer, as some join-scripts didn't terminate correctly and thus survived the join process. After that the user password of the user was visible to all other users.
Comment 10 Jan Christoph Ebersbach univentionstaff 2016-03-31 13:32:40 CEST
A customer reported the issue again at Ticket #2016033121000153
Comment 11 Stefan Gohmann univentionstaff 2016-04-25 07:52:53 CEST
This issue has been filed against UCS 2.4.

UCS 2.4 is out of maintenance and many UCS components have vastly changed in
later releases. Thus, this issue is now being closed.

If this issue still occurs in newer UCS versions, please use "Clone this bug".
In this case please provide detailed information on how this issue is affecting
you.
Comment 12 Florian Best univentionstaff 2019-02-18 17:00:31 CET

*** This bug has been marked as a duplicate of bug 46842 ***