AutoHotkey Homepage AutoHotkey Community
Let's help each other out
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

tmp and temp special variables

 
Post new topic   Reply to topic    AutoHotkey Community Forum Index -> Bug Reports
View previous topic :: View next topic  
Author Message
arbe



Joined: 12 Apr 2005
Posts: 30

PostPosted: Wed Sep 28, 2005 4:58 pm    Post subject: tmp and temp special variables Reply with quote

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
View user's profile Send private message
Chris
Site Admin


Joined: 02 Mar 2004
Posts: 10467

PostPosted: Wed Sep 28, 2005 5:00 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
arbe



Joined: 12 Apr 2005
Posts: 30

PostPosted: Sun Oct 02, 2005 10:02 am    Post subject: Reply with quote

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
View user's profile Send private message
Chris
Site Admin


Joined: 02 Mar 2004
Posts: 10467

PostPosted: Sun Oct 02, 2005 12:21 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
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...

PostPosted: Sun Oct 02, 2005 6:19 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Chris
Site Admin


Joined: 02 Mar 2004
Posts: 10467

PostPosted: Mon Oct 03, 2005 3:04 am    Post subject: Reply with quote

That's a good possibility; thanks.
Back to top
View user's profile Send private message Send e-mail
jonny



Joined: 13 Nov 2004
Posts: 3004
Location: Minnesota

PostPosted: Mon Oct 03, 2005 2:28 pm    Post subject: Reply with quote

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
View user's profile Send private message
Dewi Morgan



Joined: 03 Oct 2005
Posts: 178

PostPosted: Tue Oct 11, 2005 12:58 am    Post subject: Reply with quote

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
View user's profile Send private message
arbe



Joined: 12 Apr 2005
Posts: 30

PostPosted: Thu Jan 12, 2006 8:13 am    Post subject: Any news? Reply with quote

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
View user's profile Send private message
Chris
Site Admin


Joined: 02 Mar 2004
Posts: 10467

PostPosted: Thu Jan 12, 2006 4:45 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
kapege.de



Joined: 07 Feb 2005
Posts: 186
Location: Munich, Germany

PostPosted: Thu Jan 12, 2006 5:41 pm    Post subject: Reply with quote

Chris wrote:
It is tentatively planned to have a #v1.1 ...

Shocked Hurray it's coming! Chris said the magic word ("1.1")! Very Happy Very Happy Very Happy

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
View user's profile Send private message Visit poster's website
PhiLho



Joined: 27 Dec 2005
Posts: 6721
Location: France (near Paris)

PostPosted: Wed Feb 08, 2006 9:59 am    Post subject: Workaround Reply with quote

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
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    AutoHotkey Community Forum Index -> Bug Reports All times are GMT
Page 1 of 1

 
Jump to:  
You can post new topics in this forum
You can reply to topics in this forum


Powered by phpBB © 2001, 2005 phpBB Group