Serious privacy leak in Python for Windows
Richard M. Smith
There is a privacy leak problem in many Python implementations for
Windows which allow a malicious Web page or HTML email message to read
the contents of file from a user's hard drive and send the contents back
to a Web site. The problem occurs in Windows Python implementations
that supports Python as a scripting language for Web pages in Internet
Explorer.
The problem exists because the Python runtime library does not consider
file read operations to be a security risk. File read operations are
allowed to execute on a Web page without restriction. File write
operations, on the other hand, are blocked.
For example, the following Python code on a Web page will run
successfully:
<SCRIPT language=python>
import __builtin__
myfile = __builtin__.open("c:\\autoexec.bat")
document.write(str(myfile.readlines()))
myfile.close()
</SCRIPT>
This particular example opens the file c:\autoexec.bat and writes the
file contents to the Web page. The program could easily be changed to
send the contents of the file back to a Web site by using an HTML form,
a Web bug, or the Microsoft XML HTTP ActiveX control.
Here is a second example, that shows a directory listing of C:\ on a Web
page:
<SCRIPT language=python>
import os
for file in os.listdir("c:\\"):
document.writeln(file, "<br>");
</SCRIPT>
This directory listing example is available online to test to see if a
particular computer system is vulnerable to the problem or not:
http://www.computerbytesman.com/privacy/pythondirdemo.htm
To fix this privacy leak, the Python runtime library should block all
file operations when Python code is being used on a Web page, not just
file write operations.
There might also be workarounds to this problem either in Microsoft's
ActiveScripting support in IE or in the Python runtime library.
However, I am not an expert on either technology to know what these
work-arounds might be. Please drop me an email if you have any
suggestions.
Richard M. Smith
http://www.computerbytesman.com
Paul Rubin
> To fix this privacy leak, the Python runtime library should block all
> file operations when Python code is being used on a Web page, not just
> file write operations.
The leak is a terrible bug. Scripts on web pages/emails/etc. should
always be run in a rexec/Bastion container (for non-Pythonistas, a
"sandbox") that stops all these operations.
Hernan M. Foffani
> "Richard M. Smith" writes:
> > To fix this privacy leak, the Python runtime library should block
all
> > file operations when Python code is being used on a Web page, not
just
> > file write operations.
>
> The leak is a terrible bug. Scripts on web pages/emails/etc. should
> always be run in a rexec/Bastion container (for non-Pythonistas, a
> "sandbox") that stops all these operations.
Uninstalling win32all "solves" the problem. I don't know Windows
registry enough, but I'm pretty sure that there is a way to stop
python local scripting on IE.
-Hernan
Paul Prescod
>
I'm surprised that Python-in-IE works at all! I suspect that if we close
this loophole we'll find another and another and another. Python is not
a language designed from scratch to be sandboxed as Java and JavaScript
are. Constructing a strong sandbox is quite hard and requires careful
peer review. I doubt Python's sandbox technologies have got that level
of review and to be honest I would not trust them!
Paul Prescod
Kevin Altis
Windows? If so, perhaps someone could explain what registry tweak or file
change needs to be made to simply disable PythonScript so it is not
available in Internet Explorer or unavailable as a Windows Script Host
language.
ka
"Richard M. Smith" <r...@computerbytesman.com> wrote in message
news:3C44A774...@computerbytesman.com...
Mark Hammond
> There is a privacy leak problem in many Python implementations for
Windows
> which allow a malicious Web page or HTML email message to read the
> contents of file from a user's hard drive and send the contents
> back to a Web site. The problem occurs in Windows Python
> implementations that supports Python as a scripting language for
> Web pages in Internet Explorer.
The ActiveScripting engine in Python, when used by IE, uses the "rexec"
module to restrict what the code can do - Python's closest thing to a
"sandbox".
This rexec module does prevent file writes etc, but allows file reads -
it uses a "safety" model rather than a "privacy" model.
However, Paul Prescod wrote:
> I doubt Python's sandbox technologies have got that level of review
> and to be honest I would not trust them!
and I am inclined to agree. Guido also says as much in private mail.
So, rather than to fix this hole, I think the best solution is to
disable "safe" scripting by the Python Scripting engine. This will mean
ASP, WSH etc. will continue to work, but IE will refuse to execute the
scripts.
So: to disable ALL Python Active Scripting on your machine, simply execute:
Z:\>win32comext\axscript\client\pyscript.py --unregister
This will close the loophole, but also prevent ASP, WSH etc from working.
Later versions of win32all/ActivePython will be setup so that ASP etc
work by default, but you will need to manually register an alternative
COM object for use with IE.
Mark.
Don Tuttle
> So, rather than to fix this hole, I think the best solution is to
> disable "safe" scripting by the Python Scripting engine. This will mean
> ASP, WSH etc. will continue to work, but IE will refuse to execute the
> scripts.
Not quite sure what you mean. I found that disabling "Scipt ActiveX
controls marked safe for scripting" has no effect in IE6. The test page
http://www.computerbytesman.com/privacy/pythondirdemo.htm still works.
It took disabling "Scripting:Active Scripting" to keep IE from running the
web page's code. This stops all scripting, not just Python.
Don
Mark Hammond
I meant for the ActiveScripting engine to be changed to disable the
support. Until the new version is out, all you can reasonably do is
disable Python completely by running the "--unregister" command.
Mark.
Martin von Loewis
> This particular example opens the file c:\autoexec.bat and writes the
> file contents to the Web page. The program could easily be changed to
> send the contents of the file back to a Web site by using an HTML form,
> a Web bug, or the Microsoft XML HTTP ActiveX control.
Can you please demonstrate how you would do this? In restricted mode,
many of the Python modules (e.g. including the socket module) are not
available.
Regards,
Martin
Aahz Maruch
In article <3C44FEC0...@skippinet.com.au>,
Mark Hammond <mham...@skippinet.com.au> wrote:
>
>So: to disable ALL Python Active Scripting on your machine, simply execute:
>Z:\>win32comext\axscript\client\pyscript.py --unregister
>
>This will close the loophole, but also prevent ASP, WSH etc from working.
>
>Later versions of win32all/ActivePython will be setup so that ASP etc
>work by default, but you will need to manually register an alternative
>COM object for use with IE.
Just to be clear, precisely what versions of Python need this fix? Does
this apply only to ActiveState Python, does it apply to anyone who
downloads win32all, or does it apply to all Python downloads for
Windows?
--
--- Aahz <*> (Copyright 2002 by aa...@pobox.com)
Hugs and backrubs -- I break Rule 6 http://www.rahul.net/aahz/
Androgynous poly kinky vanilla queer het Pythonista
"There are times when effort is important and necessary, but this should
not be taken as any kind of moral imperative." --jdecker
Hernan M. Foffani
for
> Windows? If so, perhaps someone could explain what registry tweak or
file
> change needs to be made to simply disable PythonScript so it is not
> available in Internet Explorer or unavailable as a Windows Script
Host
> language.
Limited to ActiveState ActivePython AND/OR Standard Python + the win32
extension.
Mark already post the way to disable Python scripting.
I'm afraid of all the "will-be programmers" who installed AS Python.
Is there a way to warn about this issue and the registry fix?
(Funny thing, is that it could be possible to write a web page
that remotly close the door, no?)
Regards,
-Hernan
Hernan M. Foffani
Does
> this apply only to ActiveState Python, does it apply to anyone who
> downloads win32all, or does it apply to all Python downloads for
> Windows?
ups! Does Python for Windows, downloaded from python.org, have the
problem? I don't think so, but I may be wrong...
Robin Becker
Foffani <hfof...@yahoo.com> writes
affect you. I believe that comes as standard with the Activestate
distros, but the python.org stuff doesn't have it.
--
Robin Becker
Max m
> For example, the following Python code on a Web page will run
> successfully:
>
> <SCRIPT language=python>
> import __builtin__
> myfile = __builtin__.open("c:\\autoexec.bat")
> document.write(str(myfile.readlines()))
> myfile.close()
> </SCRIPT>
The obvious and simple solution could be to not surf the web from the
server using IE. There are many other browsers available which don't do
embedded activeScripting.
This is but one of the reasons that I use mozilla for browsing.
regards Max M
DeepBleu
"Max m" <ma...@mxm.dk> wrote in message news:3C45D535...@mxm.dk...
> Richard M. Smith wrote:
>
> > For example, the following Python code on a Web page will run
> > successfully:
> >
> > <SCRIPT language=python>
> > import __builtin__
> > myfile = __builtin__.open("c:\\autoexec.bat")
> > document.write(str(myfile.readlines()))
> > myfile.close()
> > </SCRIPT>
>
>
> The obvious and simple solution could be to not surf the web from the
> server using IE.
Maybe obvious and simple, but is it practical?
DeepBleu
Max m
> "Max m" <ma...@mxm.dk> wrote in message news:3C45D535...@mxm.dk...
>>The obvious and simple solution could be to not surf the web from the
>>server using IE.
>>
>
> Maybe obvious and simple, but is it practical?
> DeepBleu
Not allways certainly. Hence the "could be". I mean, I would change
browser well before I would change back to doing .asp in VBScript :-)
In fact if VBScript was a sex partner, that I woke with in my arms, it
would be so ugly that I would chew my arm of to avoid waking it up in
the morning ;-)
regards Max M
Jason Orendorff
> module to restrict what the code can do - Python's closest thing to a
> "sandbox".
>
> This rexec module does prevent file writes etc, but allows file reads -
> it uses a "safety" model rather than a "privacy" model.
Sure, by default. But it's easy to lock it down further.
class HardRExec(rexec.RExec):
ok_path = ()
ok_builtin_modules = () # probably too harsh
ok_posix_names = ()
ok_sys_names = ()
def r_open(self, file, mode='r', buf=-1):
raise IOError, "Can't open files in restricted mode."
Each of these statements (except the first) now fails:
hrx = HardRExec()
hrx.r_exec("f = open('/etc/passwd', 'r')")
hrx.r_exec("import __builtin__; __builtin__.open('/etc/passwd')")
hrx.r_exec("import os")
hrx.r_exec("import array")
It shouldn't be too hard to find the right policy.
## Jason Orendorff http://www.jorendorff.com/
Mark Hammond
I have added a little more information on this to
http://starship.python.net/crew/mhammond. I have also included a patch
to solve this problem so that IE will not work, but ASP, WSH etc will.
Please mail all reactions or problems with the patch to me.
Thanks,
Mark.
dsavitsk
"Max m" <ma...@mxm.dk> wrote in message news:3C45E519...@mxm.dk...
i find it difficult to believe that any person could be so unattractive that
chewing one's arm off would be less disruptive to their sleep than simply
gently moving one's arm.
-d
Hans Nowak
> > would be so ugly that I would chew my arm of to avoid waking it up in
> > the morning ;-)
>
> chewing one's arm off would be less disruptive to their sleep than simply
> gently moving one's arm.
You haven't worked with VBScript, eh? ;-)
--Hans (base64.decodestring('d3VybXlAZWFydGhsaW5rLm5ldA==')
# decode for email address ;-)
Site:: http://www.awaretek.com/nowak/
Mark McEahern
> In fact if VBScript was a sex partner, that I woke with in my arms, it
> would be so ugly that I would chew my arm of to avoid waking it up in
> the morning ;-)
I've never quite thought of it that way, but I'm not shocked by the strength
of your loathing for VBScript:
I wrote this on my weblog
(http://www.markmceahern.com/2001_12_30_archive#8352000):
i want to share my joy in python with the following trivia:
# let's create a dictionary
dict = {'a': 'first letter', 'b': 'second letter'}
for key in dict.keys():
print "%s = %s" % (key, dict[key])
compare that to vbscript:
' let's create a dictionary
set dict = createobject("scripting.dictionary")
dict.add "a", "first letter"
dict.add "b", "second letter"
k = dict.keys()
s = ""
for i = 0 to ubound(k)
s = s & "k = " & dict.item(k(i)) & vbCrLf
next
msgbox s ' or response.write s for asp
btw, this is an example of what people mean when they say vb is verbose.
in python, if you want a dictionary, you can just write it. not so in
vbscript. likewise, consider this abomination of syntax for accessing an
item:
dict.item(k(i))
i mean, what the f*** is that? ;-) compare that to:
dict[key]
cheers,
// mark
Max m
> I've never quite thought of it that way, but I'm not shocked by the strength
> of your loathing for VBScript:
yes it's so uneven and poorly designed. Python feels like Lego, where
everything fits where it's supposed. Ie. I cannot recall EVER having had
an off-by-one error in my Python code.
But the main problem with VBScript is that most people using it never
realise how poor it is, as they us it because it is a "Microsoft
Standard" and so is good enough.
It takes them a long time to get to know other languages. And if they in
fact ever do, it is either Java or C++.
> I wrote this on my weblog
> (http://www.markmceahern.com/2001_12_30_archive#8352000):
It doesn't seem to exist ..
> compare that to vbscript:
> ' let's create a dictionary
In fact most VBScript programmers I have ever meet has no idea what a
dictionary is! They simply never use it because it seems complicated,
and isn't part of the core language.
I have looked at quite a few VBScript apps that customers have wanted to
upgrade or reuse code from. They have ALL been a mess.
My guess is that one of the advantages of the Python users is that they
have all made a conscious decision to use Python. Most often the
decision is made on a wide background of several languages.
regards Max M
gbr...@cix.compulink.co.uk
> ' let's create a dictionary
> set dict = createobject("scripting.dictionary")
> dict.add "a", "first letter"
> dict.add "b", "second letter"
> k = dict.keys()
> s = ""
> for i = 0 to ubound(k)
> s = s & "k = " & dict.item(k(i)) & vbCrLf
> next
> msgbox s ' or response.write s for asp
You can re-write that (in ASP, in <PRE> context)
' let's create a dictionary
set dict = createobject("scripting.dictionary")
dict("a") = "first letter"
dict("b") = "second letter"
for each key in dict.keys()
response.write(key&" = "&dict(key)&vbNewLine)
next
> btw, this is an example of what people mean when they say vb is
> verbose.
Can't you think of a better one?
> in python, if you want a dictionary, you can just write it. not so in
> vbscript.
That's the only clear advantage in this example
> likewise, consider this abomination of syntax for accessing
> an
> item:
>
> dict.item(k(i))
>
> i mean, what the f*** is that? ;-) compare that to:
>
> dict[key]
This is silly. You can write dict[dict.keys()[i]] in Python, and
dict(key) in VBScript. I'm not aware of a VBScript equivalent of this
twist
# let's create a dictionary
dict = {'a': 'first letter', 'b': 'second letter'}
for item in dict.items():
print "%s = %s" % item
let alone
# let's create a dictionary
dict = {'a': 'first letter', 'b': 'second letter'}
# let's do the whole thing on one line
print '\n'.join(['%s = %s'%x for x in dict.items()])
# and again!
print '\n'.join(map(' = '.join, dict.items()))
Incidentally, does it matter that Python prints the second letter before
the first letter?
Graham
Alex Martelli
news:mailman.1011278548...@python.org...
...
> (http://www.markmceahern.com/2001_12_30_archive#8352000):
>
> i want to share my joy in python with the following trivia:
>
> # let's create a dictionary
> dict = {'a': 'first letter', 'b': 'second letter'}
> for key in dict.keys():
> print "%s = %s" % (key, dict[key])
So far so good.
> compare that to vbscript:
>
> ' let's create a dictionary
> set dict = createobject("scripting.dictionary")
> dict.add "a", "first letter"
> dict.add "b", "second letter"
> k = dict.keys()
> s = ""
> for i = 0 to ubound(k)
> s = s & "k = " & dict.item(k(i)) & vbCrLf
> next
> msgbox s ' or response.write s for asp
Unfair! If you want to use VBScript, use GOOD VBScript:
' let's create a dictionary
set dict = createobject("scripting.dictionary")
dict.add "a", "first letter"
dict.add "b", "second letter"
for each key in dict
WScript.Echo key & " = " & dict(key)
next
Here we can see the differences more precisely:
1. Python has dictionaries and their initialization as built-ins, while
VBScript uses what Python would call "a module" (actually a COM object)
and thus needs separate creation and initialization calls
This is similar to the Python vs Perl distinction on RE's: Perl has
RE's built-in, while Python uses a module and thus needs explicit
import and calls (re.search etc, where Perl would just use /.../).
I don't think Python is worse than Perl because it doesn't bundle
RE's inside the core language: I think it's better because of this.
I also agree with the design decision to have dictionaries in the
core language, _because_ they're so widely used internally too. But
it's clearly not a black-and-white issue, either way.
Of course a language may show up better if you choose an example
where it uses a built-in feature while another language must
import a module, create an external object, and suchlike. But
it's not an intrinsically fair comparison. If having stuff built
in was always a win, the most-bloated language would be best...:-).
2. Python has "output to standard-output" as built-in, while VBScript
uses external objects for that purpose. Given how marginal the
use of standard-output is in most Windows cases, that's quite a
reasonable design choice, too. Note that I'm using WScript.Echo
for the output, as the WSH is a typical way to run VBScript; if
you run this with cscript.exe, WScript.Echo calls will go to the
console, if with wscript.exe, to message-boxes instead.
Basically these points 1 and 2 tell us that VBScript is a lighter,
more-"glue" language than Python, having less built-in stuff. In
general, that is not necessarily a bad thing, just as it isn't for
Python to be lighter, more-glue, and with less built-in than Perl.
3. the syntax -- "for key in dict.keys():" vs "for each key in dict".
Who's more readable here? Fortunately, Python 2.2 gets one better
by enabling "for key in dict:" and reaches parity.
But in neither language does it make much sense to extract the
keys as array/list and then loop over INDICES inside that, when
both languages let you loop directly over the dictionary!
> btw, this is an example of what people mean when they say vb is verbose.
>
> in python, if you want a dictionary, you can just write it. not so in
> vbscript. likewise, consider this abomination of syntax for accessing an
> item:
>
> dict.item(k(i))
>
> i mean, what the f*** is that? ;-) compare that to:
>
> dict[key]
Better compare it to dict(key), which is the normal and idiomatic way
to index into dict in VBScript -- otherwise you might have to compare
with (2.2) dict.__getitem__(ks.__getitem__(i)) in Python:-).
There ARE serious points of inferiority with VBScript when compared
to Python, such as the PITIFUL "error handling" in VBScript (just not
in the same league with Python's try/except), the horrid "assignment
is a copy and the set verb cancels that" VB model (versus Python's
clean and consistent "assignment is always about references"), and
many more. But your example doesn't cut the mustard, IMHO, since
the way it uses VBScript is seriously unidiomatic and suboptimal.
Pragmatically, VBScript's greatest issue is that it's dead: Microsoft
has announced quite a while ago that there will never be another
"Visual basic scripting edition" -- rather, the scripting abilities
will be rolled into the for-$$$ professional VB product. Python, on
the other hand, is VERY much alive -- bugs will keep getting fixed,
new platforms supported as they become important, and so on.
Alex
Cameron Laird
.
.
.
>But the main problem with VBScript is that most people using it never
>realise how poor it is, as they us it because it is a "Microsoft
>Standard" and so is good enough.
.
.
Python is, too, now.
More specifically, Visual Studio .Net just became available
on the MSDN download site this week, and one of its languages
is Python. That makes possible conversations like this:
A: It's done.
M: Really? Great. How'd you code it?
A: In Python. It went well.
M: Python?!? You know we need to use
standard languages that our vendors
support. That's ...
A: But Python is. Microsoft supports it.
M: Oh! Well, in that case ...
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
David Ascher
>
> In article <3C46EB8A...@mxm.dk>, Max m <ma...@mxm.dk> wrote:
> .
> .
> .
> >But the main problem with VBScript is that most people using it never
> >realise how poor it is, as they us it because it is a "Microsoft
> >Standard" and so is good enough.
> .
> .
> .
> Python is, too, now.
>
> More specifically, Visual Studio .Net just became available
> on the MSDN download site this week, and one of its languages
> is Python. That makes possible conversations like this:
> A: It's done.
> M: Really? Great. How'd you code it?
> A: In Python. It went well.
> M: Python?!? You know we need to use
> standard languages that our vendors
> support. That's ...
> A: But Python is. Microsoft supports it.
> M: Oh! Well, in that case ...
While I love that conversation, I just need to clarify that Microsoft
doesn't support Python in VisualStudio.NET, ActiveState does as part of
its VisualPython product. We're a Visual Studio Integration Partner,
but that's not the same thing as being "Microsoft". =)
But yes -- having Python as part of Visual Studio should make corporate
acceptance of the "most powerful language you can still read"* even
easier than in the past.
-- David Ascher
ActiveState
*: Quoth Paul Dubois, in a forthcoming volume.
Mark McEahern
> But your example doesn't cut the mustard, IMHO, since
> the way it uses VBScript is seriously unidiomatic and suboptimal.
I agree. Thanks for your feedback.
Cheers,
// mark
Joshua Muskovitz
Now that is sooooo cool. It never occurred to me that you could use
string.func as a function reference for map.
--
# Joshua Muskovitz
# jo...@taconic.net
def lyyrs(sig): return '-'.join(sig.split()+["ly y'rs"])
lyyrs('Hire me! I need the work!')
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Emile van Sebille
"Joshua Muskovitz" <jo...@taconic.net> wrote in message
news:3c47b1d7$1...@corp.newsgroups.com...
> def lyyrs(sig): return '-'.join(sig.split()+["ly y'rs"])
> lyyrs('Hire me! I need the work!')
;-)
lyyrs('10k more defs make a bot)
--
Emile van Sebille
em...@fenx.com
David LeBlanc
wrote:
<snip>
>Pragmatically, VBScript's greatest issue is that it's dead: Microsoft
>has announced quite a while ago that there will never be another
>"Visual basic scripting edition" -- rather, the scripting abilities
>will be rolled into the for-$$$ professional VB product. Python, on
>the other hand, is VERY much alive -- bugs will keep getting fixed,
>new platforms supported as they become important, and so on.
>
>
>Alex
I wonder if VBS' demise isn't due to the fact that even on IIS,
Javascript usage dominated VBS by far. I heard that > 80% of all
coding is/was done using Javascript in preference to VBS.
Dave LeBlanc
Max M
> I wonder if VBS' demise isn't due to the fact that even on IIS,
> Javascript usage dominated VBS by far. I heard that > 80% of all
> coding is/was done using Javascript in preference to VBS.
It would surprise me a lot if those numbers where true. I must admit
that I have used JScript exclusively under .asp (before Python). But I
have never meet anybody else.
But then again Denmark is probably the most anal Microsoft country in
the world :-S
regards Max M