3 ms·

If your local filesystem is literally an untrusted source, then you have big problems. All your own Python code is coming from that same untrusted source, along

by pekk 13y ago

If your local filesystem is literally an untrusted source, then you have big problems. All your own Python code is coming from that same untrusted source, along with all the .pyc files in your code and on PYTHONPATH. Is a .py or a .pyc paving a path for all sorts of nasty exploits, just because it can be run? This isn't even limited to Python: every executable you are running on that machine are coming from the same untrusted source, and every binary you build on that machine is also tainted by extension. Does loading a kernel from disk pave a path for all sorts of nasty exploits?

TheLoneWolfling 13y ago
Yes, assuming that you are loading the kernel from a directory that can be accessed without privileges. Generally the Python distribution is stored in a pseudo-readonly directory without privileges. UAC on Windows, for example. That is different with reading input files - generally files like that are stored somewhere under the user folder and as such can be accessed easily. Someone could craft an input file that when opened did pretty much anything. If this is a problem for formats like PDF (and it is), why would one not consider this a problem in this case?
lvh 13y ago
I think there's a useful distinction to be made between data and code here. Your code typically writes to your data store. Your code does not typically write to your code. It's a lot more reasonable that an attacker manages to convince your code to write some malicious data, than it is that an attacker has full write access to your filesystem. As an analogy: your SQL database probably writes to a filesystem somewhere. If it's running on the same machine as your app server, it may be on the same filesystem. But, say, SQL injection attacks are still infinitely more common than "can write to the source file currently being executed". Or, to rephrase: being writable (by the user executing app code) is a default state for your data store. It isn't a default state for your app, or your kernel.
marshray 13y ago
> If your local filesystem is literally an untrusted source, then you have big problems. When has an easy to use general purpose data serialization format ever stayed put on local filesystems?

by pekk 13y ago

TheLoneWolfling 13y ago

Yes, assuming that you are loading the kernel from a directory that can be accessed without privileges. Generally the Python distribution is stored in a pseudo-readonly directory without privileges. UAC on Windows, for example. That is different with reading input files - generally files like that are stored somewhere under the user folder and as such can be accessed easily. Someone could craft an input file that when opened did pretty much anything. If this is a problem for formats like PDF (and it is), why would one not consider this a problem in this case?

lvh 13y ago

I think there's a useful distinction to be made between data and code here. Your code typically writes to your data store. Your code does not typically write to your code. It's a lot more reasonable that an attacker manages to convince your code to write some malicious data, than it is that an attacker has full write access to your filesystem. As an analogy: your SQL database probably writes to a filesystem somewhere. If it's running on the same machine as your app server, it may be on the same filesystem. But, say, SQL injection attacks are still infinitely more common than "can write to the source file currently being executed". Or, to rephrase: being writable (by the user executing app code) is a default state for your data store. It isn't a default state for your app, or your kernel.

marshray 13y ago

> If your local filesystem is literally an untrusted source, then you have big problems. When has an easy to use general purpose data serialization format ever stayed put on local filesystems?