On Tue, Apr 12, 2016 at 11:12 PM, Steven D'Aprano <st...@pearwood.info> wrote: > To give a concrete example... suppose that the C locale library is > unsafe. Further, let's suppose that the str.isdigit method calls code > from the C locale library, to determine whether or not the string is > made up of locale-specific digits. How does this make str.isdigit > (potentially) unsafe? Regardless of what happens inside the method, it > still returns either True or False and nothing else. There's no > str.isdigit API to access the locale library. > > I can think of one possible threat. Suppose that the locale library has > a bug, so that calling "aardvark".isdigit seg faults, potentially > executing arbitrary C code, but at the very least crashing the > application. Is that the sort of attack you're concerned by?
That is a potentially significant attack vector, as it depends on a lot of external-to-Python information (the current locale, for instance; and we've seen exploits that involve remotely setting environment variables, which could include LC_ALL). However, you're right that it isn't the concern here. There is one other thing to worry about, and that's anything where the "inner" system can affect or influence the "outer" system. With the str type, that's unlikely (since strings are immutable), but I raised the potential concern of the regex cache, as there's a chance someone could attack that. The mere presence of decimal.getcontext() resulted in the whole module getting off the whitelist. If you want complete isolation of one and the other, that's easy: have no communication whatsoever. But then there's no point in having them both execute in the same interpreter. You may as well create a chroot and run Python inside that, have it serialize the result to JSON and write it to stdout, which you can then retrieve. That would pretty much solve the problem. (And in fact, if I were to do-over the project where I wanted Python sandboxing, that's probably what I'd do.) ChrisA _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
