Showing posts with label security. Show all posts
Showing posts with label security. Show all posts
2008-08-01
Abstract and poster of my thesis work is online
The abstract and poster that I presented at SOUPS 2008 are now online (the poster will most likely not make a ton of sense without reading the abstract; it was more to act as a visual aide for me to explain my work than to be self-contained). It basically outlines a way for a Java developer to secure a pre-existing application against misuse of resources through AspectJ and an approach inspired originally by object-capabilities. As soon as I have a paper published and I am cleared to post it online I will (hopefully in December).
2008-07-21
Web service idea: helping identify outdated web browsers
Google, ETH, and IBM released a paper about how 59.1% of users are running the most up-to-date browser available to them, and that a decent number of people were not running fully-patched versions. From a security and standards-compliance position, this is bad.
How can this be dealt with? One suggestion made by the authors was to have an integrated part of the browser's GUI that specified how "expired" their browser is. That's a good idea, but we all know that users are slow on the pick up in terms of upgrading, as the paper points out. So what to do?
Well, what happened if a prominent warning came up on various web sites that a person visited, telling them that their browser was out of date? If instructions were included on how to update, would people actually update their browsers? If some prominent web sites had this info, it is quite possible. But having to keep track of all that user agent info would be a pain in the rear for each site.
And that is where a web service would come in handy. If there was a simple RESTful API for people to hit where the user agent for a browser could be sent to and return, in JSON, whether the browser was outdated or not, how outdated by time it was, and the severity of how outdated it is, it would make it easer for sites to include such information. One could go as far as to include a link that went to the proper page listing instructions on how to update their browser.
Do people think that would actually be useful?
How can this be dealt with? One suggestion made by the authors was to have an integrated part of the browser's GUI that specified how "expired" their browser is. That's a good idea, but we all know that users are slow on the pick up in terms of upgrading, as the paper points out. So what to do?
Well, what happened if a prominent warning came up on various web sites that a person visited, telling them that their browser was out of date? If instructions were included on how to update, would people actually update their browsers? If some prominent web sites had this info, it is quite possible. But having to keep track of all that user agent info would be a pain in the rear for each site.
And that is where a web service would come in handy. If there was a simple RESTful API for people to hit where the user agent for a browser could be sent to and return, in JSON, whether the browser was outdated or not, how outdated by time it was, and the severity of how outdated it is, it would make it easer for sites to include such information. One could go as far as to include a link that went to the proper page listing instructions on how to update their browser.
Do people think that would actually be useful?
2008-06-18
What are the ways at getting/setting a cell variable?
I have an idea brewing in my head, but it hinges on closures and preventing access to cell variables. What are the different ways on can either read or write to a cell variable from outside the closure?
Reading is pretty straightforward (I will be using Python 3.0 names): ``fxn.__func__.__closure__[0].cell_contents`` gives you direct access to the value of a cell variable. As for writing, that takes more effort:
Can anyone think up of other ways to gain read or write access to cell variables?
Reading is pretty straightforward (I will be using Python 3.0 names): ``fxn.__func__.__closure__[0].cell_contents`` gives you direct access to the value of a cell variable. As for writing, that takes more effort:
def innocent():
x = 0
class Foo:
def get(self):
return x
return Foo
cls = innocent()
ins = cls()
print('x =', ins.get())
def evil(cls):
def outside():
x = 0
def set(self, value):
nonlocal x
x = value
return set
import types
func = types.FunctionType(outside().__code__, {},
name=cls.__name__ + '.set', closure=cls.get.__closure__)
cls.set = func
evil(cls)
print('Setting to 42')
ins.set(42)
print('x =', ins.get())
Can anyone think up of other ways to gain read or write access to cell variables?
2008-01-31
Java needs to check the validity of its security policy files better
So I have been spending today trying to get an application to run under a security policy file from an Ant build file. Not exactly a complex task. And yet neither the policy file nor the Ant build file seem to have enough error checking when they are used to make sure that there are not any stupid typos.
Take the policy file for instance. The JVM makes sure it is well-formed. But if you have a Permission object listed that does not exist, there is absolutely no warning about that fact. You would think that the failure to instantiate an object would be an error, especially for something like a security policy file, but apparently not. And you can't rely on policytool since it won't let you use some substitution string as the code base location (I have my Ant build files generate the policy file as needed to make it completely platform-independent).
And for Ant build and property files, there is no checks to make sure that properties actually exist by default. So if you have a slight typo in a property name for string replacement you won't know because it will just evaluate to the empty string. You can run in verbose or debug mode, but the amount of output is a bit much.
I can't believe I am having to consider writing a verification tool for Java security policy files that makes sure that the thing has no typos. At least it would give me an excuse to learn more Jython.
Take the policy file for instance. The JVM makes sure it is well-formed. But if you have a Permission object listed that does not exist, there is absolutely no warning about that fact. You would think that the failure to instantiate an object would be an error, especially for something like a security policy file, but apparently not. And you can't rely on policytool since it won't let you use some substitution string as the code base location (I have my Ant build files generate the policy file as needed to make it completely platform-independent).
And for Ant build and property files, there is no checks to make sure that properties actually exist by default. So if you have a slight typo in a property name for string replacement you won't know because it will just evaluate to the empty string. You can run in verbose or debug mode, but the amount of output is a bit much.
I can't believe I am having to consider writing a verification tool for Java security policy files that makes sure that the thing has no typos. At least it would give me an excuse to learn more Jython.
2007-06-26
Has anyone been able to build and run my security work?
So far I only know of two people who have checked out the security work kept in the bcannon-objcap branch. The first one gets an error the instant he tries to launch the interpreter (but I don't have any debugging info to help with that). The second person can't get the linker to play nicely.
Has anyone gotten it to work? The last thing I want to know is I am the only person in the world who can build and run this thing. I don't know anything about embedding Python, especially considering my build_secure_py.sh script is doing it in the checkout directory, so I am at a loss as to what that shell script is doing wrong.
Anyway, if you have managed to get the code checked out, built, and ran run_security_tests.py (with a standard Python interpreter), please let me know!
Has anyone gotten it to work? The last thing I want to know is I am the only person in the world who can build and run this thing. I don't know anything about embedding Python, especially considering my build_secure_py.sh script is doing it in the checkout directory, so I am at a loss as to what that shell script is doing wrong.
Anyway, if you have managed to get the code checked out, built, and ran run_security_tests.py (with a standard Python interpreter), please let me know!
2007-05-30
I have finished securing the Python interpreter!
Well, after many months of work I have finally managed to secure the Python interpreter as I laid out in my security paper! The code can be found in the bcannon-objcap branch in Python's svn repository (branched off the trunk).
Since I have finally reached this point I should give an overview of what I set out to do, what I have done, and how you too can secure the Python interpreter so that tangible resources (supposedly) can't get manipulated. If you want more thorough details about how the security mechanism is supposed to work, read the paper. This post is more about the technical details and to see if anyone can find a security hole.
What I Set Out To Do
The original goal of this work was to come up with a way so that you could run Python code in an embedded Python interpreter and not worry about it opening arbitrary sockets or touching any files unless you explicitly allowed it. The hope was to get this working for applications that embed the Python interpreter so that it could be used as a springboard into allowing people to have a custom interpreter to run Python apps in securely.
This work was never meant to be an rexec replacement. While I always kept rexec in the back of my mind to make sure that something I did would not explicitly prevent some rexec solution from coming forward, it was never the end goal.
Nor was it a goal to protect intangible things such as memory or CPU usage. This was supposed to protect stuff like files and sockets; things with a concrete object representation.
Changes to Python
So, what the heck did I end up doing? In terms of Python itself, it was actually very minor. First I removed the constructor for the file type. I never thought that I could hide the file type properly, so I just crippled it so that you had to go through open() to get a initialised file object. I added a module called objcap that includes an initialisation function for allocated file objects if people really feel the need to not use open().
Second I removed the constructor from code. I added a function to objcap to deal with this. I did this as Python does not verify bytecode and so someone might be able to crash the interpreter or something with some crazy bytecode.
With those two types neutered, I turned my attention to protecting imports. With my Python implementation of import, importlib, I already knew I had the control I needed to prevent dangerous imports, but I had to make sure that the fully powered import was not exposed in the interpreter or that attributes were exposed. I wrote a simple delegate in C that I stored at sys.import_delegate that simply called what was stored at sys.import_ . This way no attributes on the callable object were exposed. Putting all in the sys module was in no way required, but it was the simplest solution for me. It could have all easily been implemented externally of the sys module if I felt like putting in the effort. =)
I also had to edit codecs so that it didn't import sys but just the one attribute it needed. That way if you imported codecs you didn't get access to the sys module for free.
The last change to Python itself was how sys was re-imported. With sys being so special it has its module dict stored with the interpreter instance. Also because sys is special there are several places in the codebase that add stuff to the sys module during interpreter initialisation. The problem is that the built-in import machinery (as it is exposed through the imp module and thus affecting importlib) caches built-in modules' dicts and some stuff gets added to sys' dict after the caching. That means if you delete the sys module and re-import it can be in bad shape. So I had to special case re-importing the sys module. This breaks calling reload() on sys, but test_xmlrpc is the only thing that I know that does that and reload() is going away in Python 3.0, so I don't care. =)
And that's it for the changes required within Python itself. It really is not extensive in any way. I also don't see a huge issue with getting the key parts (the file and code changes) into the core as long as what is needed is exposed in a reasonable extension module.
Tweaking the Interpreter
Where most of the work comes in is in tweaking interpreter stuff outside of the core code. If you look at secure_python.c in the bcannon-objcap branch you can see what is required to get a secure version of Python to run in an embedded C application with the above-mentioned changes.
Obviously the first step is to initialize the interpreter. That's easy.
Next step is to set importlib as the import machinery. That takes creating a whitelist of built-in, frozen, and extension modules you want to allow (6, 0, and 19 each, respectively, that I could find would be safe), setting an instance of controlled_importlib.ControlledImport to sys.import_, and setting __import__ to sys.import_delegate. Now all imports go through importlib which makes sure that imports are controlled. I also clear sys.meta_path and sys.path_hooks to make sure no lingering imports are there that would accidentally subvert the whitelisting.
Next sys.modules needs to be cleaned out. Starting up Python leads to a bunch of modules being imported. Most are not critical once the interpreter is up. But a handful are required for Python to work. Those required modules (__builtin__, __main__, encodings, codecs, _codecs) are left in sys.modules. The rest are swept into a dict stored in sys.modules under the ".hidden" key. That keeps the objects alive without letting them be imported. The warnings module also gets imported and then moved as it needs to get cached at the C level.
With that done sys.path_importer_cache gets cleared. I leave sys.path alone so that I can import stuff from the stdlib without issue, but it can obviously be tweaked.
Finally, open(), execfile(), and SystemExit are removed from the built-in namespace. The first two are because they open files indiscriminately. SystemExit goes away because the Python interpreter automatically tears down the interpreter if it propagates all the way up. And by not whitelisting the exceptions module you shouldn't be able to get SystemExit.
And that's that. As you can see a lot of it is externally done to Python thanks to how import statements actually call __import__ and how Python exposes so much as dictionaries.
Building and Testing
As for confirming all of this works, I have some tests in the branch. To build all of this you can run build_secure_py.sh, but this has only been used on OS X. And to run the tests execute run_security_tests.py with a *regular* Python interpreter. Stuff in tests/succeed are expected to work while stuff in tests/fail require the code being tested to be in a try statement.
Wrap-Up
If anyone checks out the code, runs it, and manages to find a way to open a file, socket, create a code object from scratch, or arbitrarily import any extension, frozen, or built-in module, please let me know! Hopefully nobody finds a way and this all holds up. If it does I will begin trying to get what I need into the core so that this work doesn't require a special checkout of Python.
Since I have finally reached this point I should give an overview of what I set out to do, what I have done, and how you too can secure the Python interpreter so that tangible resources (supposedly) can't get manipulated. If you want more thorough details about how the security mechanism is supposed to work, read the paper. This post is more about the technical details and to see if anyone can find a security hole.
What I Set Out To Do
The original goal of this work was to come up with a way so that you could run Python code in an embedded Python interpreter and not worry about it opening arbitrary sockets or touching any files unless you explicitly allowed it. The hope was to get this working for applications that embed the Python interpreter so that it could be used as a springboard into allowing people to have a custom interpreter to run Python apps in securely.
This work was never meant to be an rexec replacement. While I always kept rexec in the back of my mind to make sure that something I did would not explicitly prevent some rexec solution from coming forward, it was never the end goal.
Nor was it a goal to protect intangible things such as memory or CPU usage. This was supposed to protect stuff like files and sockets; things with a concrete object representation.
Changes to Python
So, what the heck did I end up doing? In terms of Python itself, it was actually very minor. First I removed the constructor for the file type. I never thought that I could hide the file type properly, so I just crippled it so that you had to go through open() to get a initialised file object. I added a module called objcap that includes an initialisation function for allocated file objects if people really feel the need to not use open().
Second I removed the constructor from code. I added a function to objcap to deal with this. I did this as Python does not verify bytecode and so someone might be able to crash the interpreter or something with some crazy bytecode.
With those two types neutered, I turned my attention to protecting imports. With my Python implementation of import, importlib, I already knew I had the control I needed to prevent dangerous imports, but I had to make sure that the fully powered import was not exposed in the interpreter or that attributes were exposed. I wrote a simple delegate in C that I stored at sys.import_delegate that simply called what was stored at sys.import_ . This way no attributes on the callable object were exposed. Putting all in the sys module was in no way required, but it was the simplest solution for me. It could have all easily been implemented externally of the sys module if I felt like putting in the effort. =)
I also had to edit codecs so that it didn't import sys but just the one attribute it needed. That way if you imported codecs you didn't get access to the sys module for free.
The last change to Python itself was how sys was re-imported. With sys being so special it has its module dict stored with the interpreter instance. Also because sys is special there are several places in the codebase that add stuff to the sys module during interpreter initialisation. The problem is that the built-in import machinery (as it is exposed through the imp module and thus affecting importlib) caches built-in modules' dicts and some stuff gets added to sys' dict after the caching. That means if you delete the sys module and re-import it can be in bad shape. So I had to special case re-importing the sys module. This breaks calling reload() on sys, but test_xmlrpc is the only thing that I know that does that and reload() is going away in Python 3.0, so I don't care. =)
And that's it for the changes required within Python itself. It really is not extensive in any way. I also don't see a huge issue with getting the key parts (the file and code changes) into the core as long as what is needed is exposed in a reasonable extension module.
Tweaking the Interpreter
Where most of the work comes in is in tweaking interpreter stuff outside of the core code. If you look at secure_python.c in the bcannon-objcap branch you can see what is required to get a secure version of Python to run in an embedded C application with the above-mentioned changes.
Obviously the first step is to initialize the interpreter. That's easy.
Next step is to set importlib as the import machinery. That takes creating a whitelist of built-in, frozen, and extension modules you want to allow (6, 0, and 19 each, respectively, that I could find would be safe), setting an instance of controlled_importlib.ControlledImport to sys.import_, and setting __import__ to sys.import_delegate. Now all imports go through importlib which makes sure that imports are controlled. I also clear sys.meta_path and sys.path_hooks to make sure no lingering imports are there that would accidentally subvert the whitelisting.
Next sys.modules needs to be cleaned out. Starting up Python leads to a bunch of modules being imported. Most are not critical once the interpreter is up. But a handful are required for Python to work. Those required modules (__builtin__, __main__, encodings, codecs, _codecs) are left in sys.modules. The rest are swept into a dict stored in sys.modules under the ".hidden" key. That keeps the objects alive without letting them be imported. The warnings module also gets imported and then moved as it needs to get cached at the C level.
With that done sys.path_importer_cache gets cleared. I leave sys.path alone so that I can import stuff from the stdlib without issue, but it can obviously be tweaked.
Finally, open(), execfile(), and SystemExit are removed from the built-in namespace. The first two are because they open files indiscriminately. SystemExit goes away because the Python interpreter automatically tears down the interpreter if it propagates all the way up. And by not whitelisting the exceptions module you shouldn't be able to get SystemExit.
And that's that. As you can see a lot of it is externally done to Python thanks to how import statements actually call __import__ and how Python exposes so much as dictionaries.
Building and Testing
As for confirming all of this works, I have some tests in the branch. To build all of this you can run build_secure_py.sh, but this has only been used on OS X. And to run the tests execute run_security_tests.py with a *regular* Python interpreter. Stuff in tests/succeed are expected to work while stuff in tests/fail require the code being tested to be in a try statement.
Wrap-Up
If anyone checks out the code, runs it, and manages to find a way to open a file, socket, create a code object from scratch, or arbitrarily import any extension, frozen, or built-in module, please let me know! Hopefully nobody finds a way and this all holds up. If it does I will begin trying to get what I need into the core so that this work doesn't require a special checkout of Python.
2007-04-19
Python security paper online
This past term I audited a grad course on computer security here at UBC in the EECE dept. As part of the course there was a final paper. Having already spent months on the topic of security and Python I used the course as an excuse to write up my work.
I have put the paper, "Controlling Access to Resources Within The Python Interpreter" online. There are some things you should keep in mind when reading the paper. One is that this paper was for a course, not a journal or conference. Another is that I had an eight page limit so I didn't have space to go into how the security implementation would defend against common attacks, etc. Lastly, the audience did not know Python, so there is some stuff in the paper that is probably rather basic for anyone who reads this blog.
I think the paper turned out fine. Comments on the security design are welcome. Edit issues are not too critical as this paper would most likely get reworked for a conference if it ever comes to this.
Assuming I have the time I am hoping to use this paper as a reference in a PEP to get the changes I want into Py3K. But I am not sure if I am going to have the time to pull this off by April 30th, especially if I want a proof-of-concept ready by then. So if it slips to Python 3.1/2.7 then that is life.
And a special thanks needs to go to my supervisor, Eric Wohlstadter, for funding me while doing this work. Even when it seemed we might not get a publication out of this he allowed me to continue to work on it which I really appreciate.
I have put the paper, "Controlling Access to Resources Within The Python Interpreter" online. There are some things you should keep in mind when reading the paper. One is that this paper was for a course, not a journal or conference. Another is that I had an eight page limit so I didn't have space to go into how the security implementation would defend against common attacks, etc. Lastly, the audience did not know Python, so there is some stuff in the paper that is probably rather basic for anyone who reads this blog.
I think the paper turned out fine. Comments on the security design are welcome. Edit issues are not too critical as this paper would most likely get reworked for a conference if it ever comes to this.
Assuming I have the time I am hoping to use this paper as a reference in a PEP to get the changes I want into Py3K. But I am not sure if I am going to have the time to pull this off by April 30th, especially if I want a proof-of-concept ready by then. So if it slips to Python 3.1/2.7 then that is life.
And a special thanks needs to go to my supervisor, Eric Wohlstadter, for funding me while doing this work. Even when it seemed we might not get a publication out of this he allowed me to continue to work on it which I really appreciate.
2007-02-07
Security on the OLPC laptop
This Slashdot post links to a Wired article and the spec for the security model for the OLPC XO laptops called Bitfrost. Interesting thing about it is it seems to be following the design philosophay of Principle of Least Authority (POLA). First learned of this security technique this past summer when I heard a talk by it from Alan Karp at HP. It's an interesting approach that makes sense (at least to me).
2007-01-05
OpenID is the way accounts should be manaaged
I just created an OpenID account using MyOpenID (which is run by the guys who developed one of the top libraries for OpenID, in Python of course). After reading Simon Willison's blog entry on OpenID and noticing that Ma.gnolia used it, I figured I would give it a go.
It was very painless. What was great about it is that I was able to open a Ma.gnolia account without specifying anything! My OpenID account handles the authentication stuff (so no password required for Ma.gnolia) and they then gave Ma.gnolia my email as it is required to sign up so I didn't even need to fill that in. I wish all account creation was that simple!
And although I have barely used Ma.gnolia, I have to say it is a very slick site. The interface to the site is very intuitive and they seem to provide all of the features I want for a bookmarking site.
It was very painless. What was great about it is that I was able to open a Ma.gnolia account without specifying anything! My OpenID account handles the authentication stuff (so no password required for Ma.gnolia) and they then gave Ma.gnolia my email as it is required to sign up so I didn't even need to fill that in. I wish all account creation was that simple!
And although I have barely used Ma.gnolia, I have to say it is a very slick site. The interface to the site is very intuitive and they seem to provide all of the features I want for a bookmarking site.
Subscribe to:
Posts (Atom)