Console a security issue on MS Windows?
Wojciech Kocjan
Recently I had an issue - I forgot a password and I still had the password
typed in a Tk app, in an [entry ... -show "*"] widget.
Basically, I ran the code below, got a Tk console and was able to just do
[.pass get]. While this is cool for me, I wonder if this might be
considered a security issue by someone writing an application that
shouldn't allow user to type in their commands?
package require twapi
foreach h [twapi::find_windows -text Console] {
twapi::show_window $h
}
One example that scares me is PIM software - like Password Gorilla. I was
able to get to my gorilla's console and get all the passwords I wanted
even though the main window prevented me from doing this.
For now I simply put this in my version of gorilla:
catch {console eval {bind . <Map> {wm withdraw .}}}
I'm wondering, though, what other people might be thinking about it?
--
WK
email (rot13): jbwpvrpuNGxbpwnaQBGbet
Gerald W. Lester
If you are writing a program that you do not want the user to have console
access, then define your own procedure named console that displays an error
message.
Security has to be programmed in, it is not all up to the language.
For example, one assume that your "Password Gorilla" stores the passwords in
encrypted form in its database/file. This is something that was programmed
in, the language did not automatically do it.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
Wojciech Kocjan
napisał(a):
> Wojciech Kocjan wrote:
>> Hello,
>> Recently I had an issue - I forgot a password and I still had the
>> password typed in a Tk app, in an [entry ... -show "*"] widget.
>> Basically, I ran the code below, got a Tk console and was able to just
>> do [.pass get]. While this is cool for me, I wonder if this might be
>> considered a security issue by someone writing an application that
>> shouldn't allow user to type in their commands?
> If you are writing a program that you do not want the user to have
> console access, then define your own procedure named console that
> displays an error message.
This is not quite what I meant. I meant that a lot of people use Tcl/Tk to
develop commercial/shareware applications on MS Windows, ActiveState being
one of them with TclDevKit.
For example (not that I would encourage anyone to test it :-), someone
could install TDK, run one of TDK's apps, get the Windows console when
shows up the "No valid license file found", rename some procs (like one
for exiting Tcl) to dummy ones and simply have the app working.
I personally don't have any idea how to fix that in a nice manner - and I
think commercial app developers should be aware of this, or even better,
Tk should hide that window.
Of course there are also thousands of other possibilities to do that - so
probably this one is also up to the developer to realize and fix.
> Security has to be programmed in, it is not all up to the language.
I agree. The issue for me is if the low level stuff within the language
> For example, one assume that your "Password Gorilla" stores the
> passwords in encrypted form in its database/file. This is something
> that was programmed in, the language did not automatically do it.
I can understand that. Of course someone also had to develop how to store
the files securely, and so on.
Gerald W. Lester
> Dnia 10-01-2007 o 15:00:34 Gerald W. Lester <Gerald...@cox.net>
> napisał(a):
>
>> Wojciech Kocjan wrote:
>>> Hello,
>>> Recently I had an issue - I forgot a password and I still had the
>>> password typed in a Tk app, in an [entry ... -show "*"] widget.
>>> Basically, I ran the code below, got a Tk console and was able to
>>> just do [.pass get]. While this is cool for me, I wonder if this
>>> might be considered a security issue by someone writing an
>>> application that shouldn't allow user to type in their commands?
>> If you are writing a program that you do not want the user to have
>> console access, then define your own procedure named console that
>> displays an error message.
>
> This is not quite what I meant. I meant that a lot of people use Tcl/Tk
> to develop commercial/shareware applications on MS Windows, ActiveState
> being one of them with TclDevKit.
>
> For example (not that I would encourage anyone to test it :-), someone
> could install TDK, run one of TDK's apps, get the Windows console when
> shows up the "No valid license file found", rename some procs (like one
> for exiting Tcl) to dummy ones and simply have the app working.
>
> I personally don't have any idea how to fix that in a nice manner - and
> I think commercial app developers should be aware of this, or even
> better, Tk should hide that window.
I wrote how to fix it:
catch {console hide}
proc console {args} {
tk_messageBox \
-icon error \
-message {Console window not available with this application} \
-type ok
}
You may, or may not want to add -parent.
>
> Of course there are also thousands of other possibilities to do that -
> so probably this one is also up to the developer to realize and fix.
>
>> Security has to be programmed in, it is not all up to the language.
>
> I agree. The issue for me is if the low level stuff within the language
>
>> For example, one assume that your "Password Gorilla" stores the
>> passwords in encrypted form in its database/file. This is something
>> that was programmed in, the language did not automatically do it.
>
> I can understand that. Of course someone also had to develop how to
> store the files securely, and so on.
>
> --WK
> email (rot13): jbwpvrpuNGxbpwnaQBGbet
Wojciech Kocjan
napisał(a):
> I wrote how to fix it:
>
> catch {console hide}
> proc console {args} {
> tk_messageBox \
> -icon error \
> -message {Console window not available with this application} \
> -type ok
> }
>
> You may, or may not want to add -parent.
Not quite. This does not solve the problem, since what I am able to do is
to show the console window, even after I rename/replace the console
command.
The twapi commands I mentioned can be run by *any* Tcl process (and it is
very easy to write the program in pure C).
Googie
[...]
If I understand correctly, then this is also possible in Unix
envirnoment (X11 Library).
--
Pozdrawiam! (Regards!)
Googie
Michael A. Cleverly
> Wojciech Kocjan wrote:
> [...]
>
> If I understand correctly, then this is also possible in Unix
> envirnoment (X11 Library).
Only Windows (and I guess Mac pre-OSX) has a [console] command though.
There is perhaps a similar concern with [send] though (already documented
in the man page, i.e., http://www.tcl.tk/man/tcl8.4/TkCmd/send.htm#M10).
Wojciech's observation about [console] on Windows was an eye-opener for
me. The man page for [console]
(http://www.tcl.tk/man/tcl8.4/TkCmd/console.htm) could use a simillar
Security note I think.
Michael
Pat Thoyts
This type of problem is related to the unix Tk send function in that
an application that has permission to access the windowing system can
often do more than is expected. A good example of this is once
XOpenDisplay can work then an application can examine all XEvents - so
for instance a password entry field displaying *** still had to
process the relevant X key events. I remember at university having a
program that could eavesdrop on such a system.
On Windows there is a class of attack which IIRC is called the Shatter
attack that can be used to elevate local rights if a window from the
system user gets displayed on the desktop (ie if a service causes
something to be displayed).
In all security concerns you must bear in mind the threat. If an
application is already running and has access to your desktop what are
you now trying to protect against?
--
Pat Thoyts http://www.patthoyts.tk/
To reply, rot13 the return address or read the X-Address header.
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
Larry W. Virden
Pat Thoyts wrote:
> In all security concerns you must bear in mind the threat. If an
> application is already running and has access to your desktop what are
> you now trying to protect against?
The first thing I thought of was trojan code inside commonly used
programs (like say some of the common chat programs) which would,
behind the scenes, execute code to grab the passwords from another
program and send them over the internet to a collection site...
MartinLemburg@UGS
a long time we thought, that our commercial application would be
secure, so that nobody could steal data, could steal knowledge in the
form of procedures, etc..
But we realized, that our application is not that secure, because the
language it is based on, tcl, is so open minded, so flexible, that we
couldn't be sure of having our application secured, if criminal minds
with tcl knowledge would take a look at it and would try to spy out
what ever they want.
And it's not about our (MFC built) tcl console we use, allowing to
introspect the whole system.
As example - we obfuscate our sources, but some sources are always
plain tcl, unless we don't overload the source command - e.g. the
pkgIndex.tcl or tclIndex files.
It is easy to inject code to a tcl application, that does some
introspection by overloading commands, procedures, storing data going
through those commands, or procedures, event bindings, etc..
So we thought about overloading on our own the main commands like proc
and info and to use renaming traces to detect foreign overloading and
to prevent the usage of "info body", "info args", "info defaults" that
would allow to rebuild the big tcl sided part of our application.
Additionally we thought about not obfuscating the sources, but to
encrypt the sources and to overload the source command before loading
any package, sourcing any file to allow tcl to load a total encrypted
tcl library.
But ... we are not sure ...
... about the consequences from overloading "main" commands of tcl,
... if we get the security we want,
... if we forgot some "open doors" inviting for spying and data mining,
... .
What are the experiences of other developers working on commercial
applications?
How are other commercial applications are secured against knowledge
spying, data mining, etc.?
Best regards,
Martin Lemburg
Gerald W. Lester
> Hello,
>
> a long time we thought, that our commercial application would be
> secure, so that nobody could steal data, could steal knowledge in the
> form of procedures, etc..
>
> But we realized, that our application is not that secure, because the
> language it is based on, tcl, is so open minded, so flexible, that we
> couldn't be sure of having our application secured, if criminal minds
> with tcl knowledge would take a look at it and would try to spy out
> what ever they want.
Other languages only give the illusion that they are secure. Anyone with
knowledge and access to your console can do the above in any language.
Case in point: Back in the late 1980s Digital (aka DEC) introduced license
management into VMS. This was done at the OS level in Bliss-32. Within 6
months T-shirts were available with a 3 line binary patch that you could
make to have any license check return "OK, the person has a valid license".
8-} If anything, your Tcl should be more secure because less people know Tcl
than say Java. 8-}
If someone has access and intent, you will find it almost impossible to
truly secure your application while it is running -- at best you can make it
slightly more difficult. One way to do this is to byte compile your
libraries and put them all in a starkit or into a single TBC file. Byte
compiled Tcl is at least as hard to reverse engineer as compiled C or Java
(maybe harder).
Darren New
> Other languages only give the illusion that they are secure.
http://it.slashdot.org/article.pl?sid=07/01/13/181222&from=rss
--
Darren New / San Diego, CA, USA (PST)
Scruffitarianism - Where T-shirt, jeans,
and a three-day beard are "Sunday Best."
Donald Arseneau
> It is easy to inject code to a tcl application,
Why do you say that?
Surely you aren't executing code entered by the user!
--
Donald Arseneau as...@triumf.ca
MartinLemburg@UGS
> Why do you say that?
> Surely you aren't executing code entered by the user!
no, but take a pkgIndex.tcl file, write some code into it and start the
application!
The code will be executed, right?
That's one example, how to incect code. Another is to use the plain
ASCII files of the tcl library, like init.tcl!
Or am I wrong?
Martin
On Jan 15, 10:03 pm, Donald Arseneau <a...@triumf.ca> wrote:
> "MartinLemburg@UGS" <martin.lemburg....@gmx.net> writes:
> > It is easy to inject code to a tcl application,Why do you say that?
> Surely you aren't executing code entered by the user!
>
> --
> Donald Arseneau a...@triumf.ca
Ralf Fassel
| no, but take a pkgIndex.tcl file, write some code into it and start
| the application!
~/.wishrc will do.
| The code will be executed, right?
If the file is located somewhere in $auto_path, yes. But if the
program requires *that* level of security, you'd better control all of
the other possibilities as well (environment, HOME,
application-specific startup files etc).
R'
Donal K. Fellows
> ~/.wishrc will do.
That is only processed when running interactively. It is ignored when
running with a script.
Donal.
Bruce Hartweg
> Hi Donald,
>
>> Why do you say that?
>> Surely you aren't executing code entered by the user!
>
> no, but take a pkgIndex.tcl file, write some code into it and start the
> application!
>
> The code will be executed, right?
>
> That's one example, how to incect code. Another is to use the plain
> ASCII files of the tcl library, like init.tcl!
>
> Or am I wrong?
>
*any* language program. If I have access to muck with your file
system I can screw with your init.tcl file, I can replace a jar
file with trojans, I can update commonly used shared lib for C or
C++ runtimes, etc. etc.
Bruce
Donald Arseneau
> > Why do you say that?
> > Surely you aren't executing code entered by the user!
>
> no, but take a pkgIndex.tcl file, write some code into it and start the
> application!
Isn't that is the same vulnerability as any program that loads
libraries on the user's system? If you have security problems
you would statically link a compiled program, and make a Tcl
program self-contained also.
--
Donald Arseneau as...@triumf.ca