| View previous topic :: View next topic |
| Author |
Message |
arbe
Joined: 12 Apr 2005 Posts: 30
|
Posted: Wed Sep 28, 2005 4:58 pm Post subject: tmp and temp special variables |
|
|
| Code: | msgbox %tmp%
msgbox %temp% |
reveals that these two variables are special, but they do neither begin with A_ nor are they documented in the help.
I would appreciate if only A_TempDir could be loaded with the path to the user's temporary file directory. |
|
| Back to top |
|
 |
Chris Site Admin
Joined: 02 Mar 2004 Posts: 10467
|
Posted: Wed Sep 28, 2005 5:00 pm Post subject: |
|
|
| It's not a bug; those are environment variables. The help file explains that when your script accesses an empty variable, AHK checks to see if that variable exists as an environment variable, and if so it retrieves the string from there. |
|
| Back to top |
|
 |
arbe
Joined: 12 Apr 2005 Posts: 30
|
Posted: Sun Oct 02, 2005 10:02 am Post subject: |
|
|
Chris, thanks for your explanation.
Is there any way to turn this behaviour off? If empty variables are always checked against environment variables, one cannot write deterministic scripts, since you don't know the environment of the target machine.
For example, I want to load clipboard contents and add an error handler, if the clipboard was empty. If the variable, I loaded the (empty) contents to, is registered as an environment variable, the error check will think the clipboard was not empty.
If this is unclear, here is some code:
| Code: | temp:=Clipboard
if temp=
MessageBox error |
The script completely depends on the environment variable settings now. |
|
| Back to top |
|
 |
Chris Site Admin
Joined: 02 Mar 2004 Posts: 10467
|
Posted: Sun Oct 02, 2005 12:21 pm Post subject: |
|
|
Although there's currently no way to turn it off, your points are well made. I'll add it to the to-do list.
Thanks. |
|
| Back to top |
|
 |
JSLover
Joined: 20 Dec 2004 Posts: 542 Location: LooseChange911.com... the WTC attacks were done by the US Gov't... the official story is a lie...
|
Posted: Sun Oct 02, 2005 6:19 pm Post subject: |
|
|
| Chris wrote: | | Although there's currently no way to turn it off, your points are well made. I'll add it to the to-do list. |
Perhaps...
| Code: | #Environment On|Off|Prefix
On Perhaps have a way to turn it back on?
Off Well, um, off.
Prefix Any string to be taken as an Environment prefix.
; --------------------------------------------------------------------------
; Example 1...
msgbox, %temp% ; shows temp dir
#Environment Off
msgbox, %temp% ; blank (unless set in script)
; --------------------------------------------------------------------------
; Example 2...
msgbox, %temp% ; shows temp dir
#Environment E_
msgbox, %temp% ; blank (unless set in script)
msgbox, %e_temp% ; e_ prefix specified, any vars with that prefix are
; searched in the Environment (but without the prefix)
; (perhaps allow assigning vars with this prefix directly
; to the Environment, like EnvSet)
; --------------------------------------------------------------------------
; Example 3...different directive name...
#EnvMode On|Off|Prefix |
_________________
Home • Click image! • Blog |
|
| Back to top |
|
 |
Chris Site Admin
Joined: 02 Mar 2004 Posts: 10467
|
Posted: Mon Oct 03, 2005 3:04 am Post subject: |
|
|
| That's a good possibility; thanks. |
|
| Back to top |
|
 |
jonny
Joined: 13 Nov 2004 Posts: 3004 Location: Minnesota
|
Posted: Mon Oct 03, 2005 2:28 pm Post subject: |
|
|
A workaround would be to store the contents of the environment variable at the start of the script, and then check for that instead of checking for a blank var. If it was empty or nonexistent it will still work the same anyway. The only downside is that environment vars can change.
Another alternative is to get into the habit of using prefixes for your variables. |
|
| Back to top |
|
 |
Dewi Morgan
Joined: 03 Oct 2005 Posts: 178
|
Posted: Tue Oct 11, 2005 12:58 am Post subject: |
|
|
Trouble is, while you may use prefixes for your variables, your script is still vulnerable to an env var of the same name. Which is dream territory for a hacker.
This is why, in PHP, they made the radical change of setting "register globals" to be off by default, despite the fact that this broke the vast majority of scripts.
The fix for the broken scripts is to change the scripts to add a line at the top that registers the environment variables as variables. And nobody thought it was a bad thing that all the PHP scripts everywhere in the world needed to be fixed, because register globals had always been such an intrinsically bad and insecure thing.
For example, my PHP library has a function that checks a username and password against a database, and returns the matching userid, or null if none is found. Like so:
| Code: | my_userid = validateUser(password)
If (my_userid)
MsgBox Logged in, %my_userid%! You may now launch the missiles.
Else
MsgBox Login Failed. Stand where you are and await termination. |
Now, what happens when someone creates an environment variable called "my_userid", and fills it with anything they like? Of course, there's some security through obscurity, in that they can't see the code and can't guess the name. But if the source is known, then the system can be trivially broken, which isn't the case where there are no system-imposed variables.
Once arbitrary code becomes runnable, this will become a far greater risk, like the following, in a kiosk shell:
| Code: |
InputBox, output ,, Gimme some safe code to run.
if (output)
{
script = stripUnsafeCode(output)
if (script)
RunAHKCode, %script%
}
|
That LOOKS safe, even to an experienced eye, assuming that StripUnsafeCode() works right and removes any nasty code from the input string. But if the user can set environment variables, then it's not: there's a code injection vulnerability.
See if you can spot it before reading on.
OK, the attacker provides 100% unsafe code as the input, which all gets stripped out. But he also provides unsafe code as an environment variable called SCRIPT. So it passes the first test (if (output)), then gives an empty value into %script%, but since there's an environment variable called SCRIPT, he passes the next test (if (script)), and then gets to execute the code held in the SCRIPT env var without any filtering.
It's not that it's impossible to code around it so that there are never any cases in which this becomes a security issue. It's just Really Hard, as opposed to most of AHK which is easy like falling off a log. _________________ Yet another hotkeyer. |
|
| Back to top |
|
 |
arbe
Joined: 12 Apr 2005 Posts: 30
|
Posted: Thu Jan 12, 2006 8:13 am Post subject: Any news? |
|
|
Hi Chris,
are there any news about the implementation of this feature?
This security related issue is getting more and more attention. A recent report about undefined behavior caused by uninitialized variables (that has been cited by the renowned german Heise magazine recently) can be found here: http://www.felinemenace.org/~mercy/papers/UBehavior/Undefined%20Behavior.pdf |
|
| Back to top |
|
 |
Chris Site Admin
Joined: 02 Mar 2004 Posts: 10467
|
Posted: Thu Jan 12, 2006 4:45 pm Post subject: |
|
|
It is tentatively planned to have a #v1.1 directive that when present in scripts running on versions older than 1.1, puts 1.1 behavior into effect. One such behavior would be turning off the automatic fetching of environment variables whenever an empty variable is referenced.
This option may also arrive sooner as a separate directive.
Edit: v1.0.43.08 introduces the #NoEnv directive, which is recommended for all new scripts.
Last edited by Chris on Wed Apr 19, 2006 2:19 pm; edited 1 time in total |
|
| Back to top |
|
 |
kapege.de
Joined: 07 Feb 2005 Posts: 186 Location: Munich, Germany
|
Posted: Thu Jan 12, 2006 5:41 pm Post subject: |
|
|
| Chris wrote: | | It is tentatively planned to have a #v1.1 ... |
Hurray it's coming! Chris said the magic word ("1.1")!
Thank you Chris for all your great work! I'm longingly awaiting the 1.1. _________________ Peter
Wisenheiming for beginners: KaPeGe (German only, sorry) |
|
| Back to top |
|
 |
PhiLho
Joined: 27 Dec 2005 Posts: 6721 Location: France (near Paris)
|
Posted: Wed Feb 08, 2006 9:59 am Post subject: Workaround |
|
|
For those, like me, [re]discovering this thread, shimanov made a script to workaround this problem. _________________
vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2") |
|
| Back to top |
|
 |
|