Hi all,
When I enabled logging of stack traces, the user passwords are being written
in cleartext in the log files!
I enabled stack tracing by adding the the following line in
RT_SiteConfig.pm:
Set($LogStackTraces, 4);
Can somebody please fix this serious error so that passwords are encrypted?
I am using RT 3.8.1 installed
from ports on a FreeBSD machine. (Actually I think I got a patch from
someone in this mailing list.) If
the error has been fixed in 3.8.2, please let me know.
Also, if a 3.8.2 port is available, is it stable enough to update my 3.8.1
version?
Thanks,
Akash.
Also, if a 3.8.2 port is available, is it stable enough to update my
3.8.1
version?
The 3.8.2 port update is here: 131167 – upgrade www/rt38 to 3.8.2, optionally remove graphviz dependancy
And we’ve been running it for a week with no problems. The change
from 3.8.1 to 3.8.2 was only the version number in the port
configuration 
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source
and other randomness
Akash,
Just as a general point of etiquette, it’s customary to notify vendors
of security related issues privately before publicly announcing them.
Posting the details of security-related issues to a public mailinglist
without giving the folks who make a package to address a potential
vulnerability is irresponsible and potentially dangerous.
Thankfully, at first glance, it looks like the issue you’ve run into
isn’t particularly dangerous. RT ships with stack trace logging
disabled and generally the folks who have access to application logs
are also the folks who manage the application.
I do believe that the issue you’ve noticed merits a note in the config
file that it’s possible for sensitive data to get logged if that
function is enabled. I intend to make that change for RT 3.8.3, but
don’t currently believe that this issue requires an accelerated release
schedule.
Best,
Jesse Vincent
Best PracticalOn Mon 2.Feb’09 at 17:26:14 -0500, Akash wrote:
Hi all,
When I enabled logging of stack traces, the user passwords are being
written in cleartext in the log files!
I enabled stack tracing by adding the the following line in
RT_SiteConfig.pm:
Set($LogStackTraces, 4);
Can somebody please fix this serious error so that passwords are
encrypted? I am using RT 3.8.1 installed
from ports on a FreeBSD machine. (Actually I think I got a patch from
someone in this mailing list.) If
the error has been fixed in 3.8.2, please let me know.
Also, if a 3.8.2 port is available, is it stable enough to update my 3.8.1
version?
Thanks,
Akash.
The rt-users Archives
Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com
Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Thankfully, at first glance, it looks like the issue you’ve run into
isn’t particularly dangerous. RT ships with stack trace logging
disabled and generally the folks who have access to application logs
are also the folks who manage the application.
I can’t say that I find the latter point particularly relevant, as many
users are in the habit of re-using passwords across multiple sites.
If I, as an RT admin, have access to my RT users’ passwords, then that
may not present any risk to the security of my RT installation (as
admin, I have full access anyhow), but it does potentially place those
users’ email accounts, bank accounts, etc. at risk if they use the same
passwords on those sites as they do on my RT install.
This isn’t a serious issue for me personally (I use unique passwords for
each site where I care about security and I don’t currently use any RTs
other than my own), but it is definitely significant in the larger
scheme of things due to the risk it presents to users who choose to
maintain a smaller collection of passwords.
Dave Sherohman
NomadNet, Inc.
http://nomadnetinc.com/
Dave Sherohman schrieb:
I can’t say that I find the latter point particularly relevant, as many
users are in the habit of re-using passwords across multiple sites.
If I, as an RT admin, have access to my RT users’ passwords, then that
may not present any risk to the security of my RT installation (as
admin, I have full access anyhow), but it does potentially place those
users’ email accounts, bank accounts, etc. at risk if they use the same
passwords on those sites as they do on my RT install.
If such people want to find out users passwords in order to try them out
elsewhere, they could just remove the cloaking of passwords from the RT
source, or sniff the http packets (or set up a man-in-the-middle-attack
if RT is using HTTPS), or design their own login page that writes down
the passwords before passing them to RT, or…
In many organizations, it is policy that admins do not know and cannot
recover their users passwords, including ours. That’s OK for secure
applications and authentication frameworks like Windows domain logons or
Kerberos. But there’s no way to secure a plain http login against your
own admins. You will have to use some other form of authentication for
RT if you want this.
Bye,
Andreas
Well, the point is that it is wrong for anyone (even the admin) to know the
passwords of any user “in the clear” just by looking at the log files.
(How someone can obtain the passwords is a different matter.)On Tue, Feb 3, 2009 at 7:55 AM, Andreas Heinlein aheinlein@gmx.com wrote:
Dave Sherohman schrieb:
I can’t say that I find the latter point particularly relevant, as many
users are in the habit of re-using passwords across multiple sites.
If I, as an RT admin, have access to my RT users’ passwords, then that
may not present any risk to the security of my RT installation (as
admin, I have full access anyhow), but it does potentially place those
users’ email accounts, bank accounts, etc. at risk if they use the same
passwords on those sites as they do on my RT install.
If such people want to find out users passwords in order to try them out
elsewhere, they could just remove the cloaking of passwords from the RT
source, or sniff the http packets (or set up a man-in-the-middle-attack
if RT is using HTTPS), or design their own login page that writes down
the passwords before passing them to RT, or…
In many organizations, it is policy that admins do not know and cannot
recover their users passwords, including ours. That’s OK for secure
applications and authentication frameworks like Windows domain logons or
Kerberos. But there’s no way to secure a plain http login against your
own admins. You will have to use some other form of authentication for
RT if you want this.
Bye,
Andreas
The rt-users Archives
Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com
Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Dave Sherohman schrieb:
I can’t say that I find the latter point particularly relevant, as many
users are in the habit of re-using passwords across multiple sites.
If I, as an RT admin, have access to my RT users’ passwords, then that
may not present any risk to the security of my RT installation (as
admin, I have full access anyhow), but it does potentially place those
users’ email accounts, bank accounts, etc. at risk if they use the same
passwords on those sites as they do on my RT install.
If such people want to find out users passwords in order to try them out
elsewhere, they could just remove the cloaking of passwords from the RT
source, or sniff the http packets (or set up a man-in-the-middle-attack
if RT is using HTTPS), or design their own login page that writes down
the passwords before passing them to RT, or…
Fair point, but I still see a significant difference between “turn on
this switch and we’ll hand you the passwords in a log file” and the
various methods you mention, any of which would require some degree of
skill and/or effort to implement. Doubly so when the switch in question
has other, legitimate, uses which can result in the admin accidentally
making a plaintext record of the passwords without even realizing it.
Dave Sherohman
NomadNet, Inc.
http://nomadnetinc.com/
Akash wrote:
Well, the point is that it is wrong for anyone (even the admin) to know the
passwords of any user “in the clear” just by looking at the log files.
(How someone can obtain the passwords is a different matter.)
I disagree. On rare occasions, characters within a password can cause
problems - especially in systems where there are proxies or other
handlers such as FastCGI or mod_perl2 which can exert their own
translations to the data they handle. It’s always useful, in that event,
to be able to switch the debug level up and see what data the
application is processing.
I’ve seen several system problems in the past caused by poor, limited or
non-existent escaping of characters in passwords which get translated
into something else by the processing system. Think UTF-8 to other
charset conversions, for example.
It shouldn’t be the normal mode of operation, but a high level of debug
info is always a useful tool to have.
Graeme
Graeme Fowler
Team Manager, Internet Services and Software Solutions, IT Services
Loughborough University, UK
T: +44 1509 226014 E: G.E.Fowler@lboro.ac.uk
I would agree with Jesse input that the first email should have gone to
best practical and not a mailing list, I would also agree with Jesse and
a couple others that this is “not” a security risk …
The fact that a sys admin can see a users password and then use it on
bank accounts or anything else is a very scary thought, this sys admin
may have access to far more sensitive systems such as finance or billing
where he/she would be able to access far more information easier and
quicker …
I personally think its a bug that should be looked at, but its not a
security risk.
Regards;
Roy
Dave Sherohman wrote:> On Tue, Feb 03, 2009 at 01:55:41PM +0100, Andreas Heinlein wrote:
Dave Sherohman schrieb:
I can’t say that I find the latter point particularly relevant, as many
users are in the habit of re-using passwords across multiple sites.
If I, as an RT admin, have access to my RT users’ passwords, then that
may not present any risk to the security of my RT installation (as
admin, I have full access anyhow), but it does potentially place those
users’ email accounts, bank accounts, etc. at risk if they use the same
passwords on those sites as they do on my RT install.
If such people want to find out users passwords in order to try them out
elsewhere, they could just remove the cloaking of passwords from the RT
source, or sniff the http packets (or set up a man-in-the-middle-attack
if RT is using HTTPS), or design their own login page that writes down
the passwords before passing them to RT, or…
Fair point, but I still see a significant difference between “turn on
this switch and we’ll hand you the passwords in a log file” and the
various methods you mention, any of which would require some degree of
skill and/or effort to implement. Doubly so when the switch in question
has other, legitimate, uses which can result in the admin accidentally
making a plaintext record of the passwords without even realizing it.
–
Dave Sherohman
NomadNet, Inc.
http://nomadnetinc.com/
The rt-users Archives
Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com
Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Dave Sherohman schrieb:> On Tue, Feb 03, 2009 at 01:55:41PM +0100, Andreas Heinlein wrote:
Dave Sherohman schrieb:
I can’t say that I find the latter point particularly relevant, as many
users are in the habit of re-using passwords across multiple sites.
If I, as an RT admin, have access to my RT users’ passwords, then that
may not present any risk to the security of my RT installation (as
admin, I have full access anyhow), but it does potentially place those
users’ email accounts, bank accounts, etc. at risk if they use the same
passwords on those sites as they do on my RT install.
If such people want to find out users passwords in order to try them out
elsewhere, they could just remove the cloaking of passwords from the RT
source, or sniff the http packets (or set up a man-in-the-middle-attack
if RT is using HTTPS), or design their own login page that writes down
the passwords before passing them to RT, or…
Fair point, but I still see a significant difference between “turn on
this switch and we’ll hand you the passwords in a log file” and the
various methods you mention, any of which would require some degree of
skill and/or effort to implement.
aptitude install dsniff
dsniff -i eth0 > passwords.txt
That’s it, basically
(when run on the RT server)
Bye,
Andreas
Dave Sherohman schrieb:
Fair point, but I still see a significant difference between “turn on
this switch and we’ll hand you the passwords in a log file” and the
various methods you mention, any of which would require some degree of
skill and/or effort to implement.
aptitude install dsniff
dsniff -i eth0 > passwords.txt
That’s it, basically
(when run on the RT server)
Yup. I didn’t say it would be a large degree of skill or effort
involved. 
(And, personally, I prefer ngrep. Something like
ngrep -d eth0 password dst port 80 > passwords.txt
wouldn’t capture nearly as much random traffic along with the
passwords.)
Dave Sherohman
NomadNet, Inc.
http://nomadnetinc.com/
Thankfully, at first glance, it looks like the issue you’ve run into
isn’t particularly dangerous. RT ships with stack trace logging
disabled and generally the folks who have access to application logs
are also the folks who manage the application.
The docs for ‘LogStackTrace’ have been updated as follows. How do
folks feel about the new notice?
If set to a log level then logging will include stack
traces for messages with level equal to or greater than
specified.
NOTICE: Stack traces include parameters that functions or methods
were called wiht. It is possible for stack trace logging to revealsensitive information such as passwords or ticket content in yourlogs.
The docs for ‘LogStackTrace’ have been updated as follows. How do
folks feel about the new notice?
If set then logging will include stack
traces for messages with level equal or greater than
specified.
NOTICE: Stack traces include parameters that functions or methods
were called with. It is possible for stack trace logging to reveal sensitive
information such as passwords and ticket content in your logs.
Jesse,
Since you’re asking (and towards the goal of something useful coming from
this thread).
I would say that, in this case, you shouldn’t end a sentence with a
preposition.
How about:
“Stack traces include the parameters of called functions.”
or
“Stack traces include the parameters used within methods and functions.”
or
…
Isaac Vetter
Isaac Vetter wrote:
The docs for ‘LogStackTrace’ have been updated as follows. How do
folks feel about the new notice?
If set then logging will include stack
traces for messages with level equal or greater than
specified.
NOTICE: Stack traces include parameters that functions or methods
were called with. It is possible for stack trace logging to reveal sensitive
information such as passwords and ticket content in your logs.
Jesse,
Since you’re asking (and towards the goal of something useful coming from
this thread).
I would say that, in this case, you shouldn’t end a sentence with a
preposition.
How about:
“Stack traces include the parameters of called functions.”
or
“Stack traces include the parameters used within methods and functions.”
or
…
One idea I’ve seen and quite like is what OpenLDAP does. Passwords and
other security tokens are Base64 encoded in all output[*]. Sure it’s a
trivial encoding that anyone could decode in moments, but it prevents
people trivially reading passwords over your shoulder when they are
displayed on your screen.
Cheers,
Matthew
[*] Actually I think this is primarily because those object classes are
defined as containing non-ascii data, rather than specifically as a
security measure. It’s a handy side-effect though.
Dr Matthew Seaman The Bunker, Ash Radar Station
PGP: 0x60AE908C on servers Marshborough Rd
Tel: +44 1304 814890 Sandwich
Fax: +44 1304 814899 Kent, CT13 0PL, UK
signature.asc (259 Bytes)
One idea I’ve seen and quite like is what OpenLDAP does. Passwords and
other security tokens are Base64 encoded in all output[*]. Sure it’s a
trivial encoding that anyone could decode in moments, but it prevents
people trivially reading passwords over your shoulder when they are
displayed on your screen.
Are you sure what you’re actually looking at isn’t a password hash?
That’s what you’d normally expect to find in the userPassword
attribute, and isn’t the same thing at all.
Dominic Hargreaves, Systems Development and Support Team
Computing Services, University of Oxford
The docs for ‘LogStackTrace’ have been updated as follows. How do
folks feel about the new notice?
If set then logging will include stack
traces for messages with level equal or greater than
specified.
NOTICE: Stack traces include parameters that functions or methods
were called with. It is possible for stack trace logging to reveal sensitive
information such as passwords and ticket content in your logs.
Jesse,
Since you’re asking (and towards the goal of something useful coming from
this thread).
I would say that, in this case, you shouldn’t end a sentence with a
preposition.
How about:
“Stack traces include the parameters of called functions.”
or
“Stack traces include the parameters used within methods and functions.”
or
…
I’ve just checked in this:
NOTICE: Stack traces include parameters supplied to functions or
methods. It is possible for stack trace logging to reveal sensitive
information such as passwords or ticket content in your logs.
The docs for ‘LogStackTrace’ have been updated as follows. How do
folks feel about the new notice?
If set then logging will include stack
traces for messages with level equal or greater than
specified.
NOTICE: Stack traces include parameters that functions or methods
were called with. It is possible for stack trace logging to reveal sensitive
information such as passwords and ticket content in your logs.
Jesse,
Since you’re asking (and towards the goal of something useful coming from
this thread).
I would say that, in this case, you shouldn’t end a sentence with a
preposition.
How about:
“Stack traces include the parameters of called functions.”
or
“Stack traces include the parameters used within methods and functions.”
or
…
I’ve just checked in this:
NOTICE: Stack traces include parameters supplied to functions or
methods. It is possible for stack trace logging to reveal sensitive
information such as passwords or ticket content in your logs.
That sounds perfect. Once i was done testing ExternalAuth, i turned
off stack traces then manually blew away those sections of the logs
that contained the passwords anyway, just to keep in paranoia
practice.
/chown -R us:us /yourbase