*possible* RT security bug

Version 3.8.2

Noticed when writing a plugin. I have debugging that prints out the
content of %ARGS. I went to the page while not logged in, it prompted
for login. Logged in and it redirected to the page I am working on. the
debugging showed the username and password in %ARGS.

I would expect the username and password to be stripped from %ARGS the
moment the login validation stage is complete (on success or failure). I
do not have any clear ideas on how to exploit this, but it seems pretty
sketch.

-Chad Granum

signature.asc (252 Bytes)

Version 3.8.2

Noticed when writing a plugin. I have debugging that prints out the
content of %ARGS. I went to the page while not logged in, it prompted
for login. Logged in and it redirected to the page I am working on. the
debugging showed the username and password in %ARGS.

Chad,

I would expect the username and password to be stripped from %ARGS the
moment the login validation stage is complete (on success or failure). I
do not have any clear ideas on how to exploit this, but it seems pretty
sketch.

Your expectation isn’t really consistent with my experiences of web
application development, especially in a dynamic language like Perl.
If you’re writing code linked into RT (as it is when you write an RT
plugin) you have full access to the application’s internals. That means
you have full access to RT’s internal data structures, database handle,
etc. Once you have access to the app’s internals, it’s trivial to hook
into any stage of the request process. A malicious developer can
trivially subvert any part of the request process. Stripping out request
data after processing won’t stop them. It will, however, lead to weird,
inconsistent results for legitimate development.

I hope that explanation makes some sense. I’m happy to discuss this
further.

Best,
Jesse