Re: hiding global variables

On Nov 4, 10:21 am, yahalom <yahal...@xxxxxxxxx> wrote:
On Nov 3, 10:21 pm, Alexandre Ferrieux <alexandre.ferri...@xxxxxxxxx>

On Nov 3, 11:54 am, yahalom <yahal...@xxxxxxxxx> wrote:

On Nov 3, 3:12 am, Alexandre Ferrieux <alexandre.ferri...@xxxxxxxxx>

On Nov 2, 3:58 pm, yahalom <yahal...@xxxxxxxxx> wrote:


we are using aes package and we want the key to be global so all
places using the package can use this global variable. we thought of
keeping the global creation key in one utilites file that is sourced
by all. we use tclcompiler to bytecode the application so all is
hidden. but tcl introspection abilities (info globals) allow me to see
that there is a global variable which then easily is seen. how can I
hide this global variable? is there another approach for a global key
file being used in many places in the files? what I want is to make it
hard for a hacker to find out the key. I know I can hard code the key
in all files and use 'sed' or something like it to change the key but
this will create a big overhead for patches.

In what situation does your hacker get access to the interpreter, in
order to be able to ask [info globals] ?
Also, be warned that the Tcl level is not the only one to consider:
the same hacker could quite easily intercept syscalls and get the I/O
reading the key...
Making all this hard is the point of complex crypto APIs, so I
wouldn't count on a robust solution with plain I/O of the secret
key ;-)


the key file is encrypted so the syscall interception will not help
him. I am also aware that nothing is full proof. I was just wondering
if there is a way to hide global var that will hold the key to open
the encrypted key file. with tcl introspection abilites it looks
impossible but maybe someone has idea.

You didn't answer the main question: In what situation does your
hacker get access to the interpreter, in order to be able to ask [info
globals] ?

That's important, because you may be placing the security fence at the
wrong place.

we run our software with tclsh and we have packages. our software is
installed in many customers sites with workers that might have access
to the system. we hold sensitive data so we encrypt it. but those who
roam around the system might want to look at it. they can play with
tclsh and start investigating. the issue is even harder as we want the
key to be hidden from our own developers (only a security officer
should know it). This is the hardest one as they know the code. I know
this might be asking too much but pci regulations are about making it

Strange, didn't you say you were shipping standalone apps in
bytecode ?
In that case, just compile code that does not return (ie finishes by
an endless processing loop).
Then, unless you do obviously dangerous things like [subst] or [eval]
on uncontrolled input, there is no way for anybody to eval arbitrary
Of course one advanced hacker could compile a custom tclsh with
instrumented primitives, but all this is just a matter of degree...