Re: [Python-Dev] Hash collision security issue (now public)
On Wed, Jan 4, 2012 at 12:02 AM, Bill Janssen wrote: > Christian Heimes wrote: > >> Am 29.12.2011 12:13, schrieb Mark Shannon: >> > The attack relies on being able to predict the hash value for a given >> > string. Randomising the string hash function is quite straightforward. >> > There is no need to change the dictionary code. >> > >> > A possible (*untested*) patch is attached. I'll leave it for those more >> > familiar with unicodeobject.c to do properly. >> >> I'm worried that hash randomization of str is going to break 3rd party >> software that rely on a stable hash across multiple Python instances. >> Persistence layers like ZODB and cross interpreter communication >> channels used by multiprocessing may (!) rely on the fact that the hash >> of a string is fixed. > > Software that depends on an undefined hash function for synchronization > and persistence deserves to break, IMO. There are plenty of > well-defined hash functions available for this purpose. > > Bill > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/fijall%40gmail.com A lot of software will break their tests, because dict ordering would depend on the particular run. I know, because some of them break on pypy which has a different dict ordering. This is probably a good thing in general, but is it really worth it? People will install python 2.6.newest and stuff *will* break. Is it *really* a security issue? We knew all along that dicts are O(n^2) in worst case scenario, how is this suddenly a security problem? Cheers, fijal ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RNG in the core
> Well what if /dev/urandom is unavailable because the program is run > e.g. in a chroot? If the system ought to have /dev/urandom (as e.g. determined during configure), I propose that Python fails fast, unless the command line option is given that disables random hash seeds. For the security fixes, we therefore might want to toggle the meaning of the command line switch, i.e. only use random seeds if explicitly requested. > (or is /dev/urandom still available in a chroot?) You can make it available if you want to: just create a /dev directory, and do mknod in it. It's common to run /dev/MAKEDEV (or similar), or to mount devfs into a chroot environment; else many programs run in the chroot are likely going to fail (e.g. if /dev/tty is missing). See, for example, http://tldp.org/HOWTO/Chroot-BIND-HOWTO-2.html bind apparently requires /dev/null and /dev/random. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hash collision security issue (now public)
On Wed, 4 Jan 2012 09:59:15 +0200 Maciej Fijalkowski wrote: > > Is it *really* a security issue? We knew all along that dicts are > O(n^2) in worst case scenario, how is this suddenly a security > problem? Because it has been shown to be exploitable for malicious purposes? Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hash collision security issue (now public)
Am 04.01.2012 08:59, schrieb Maciej Fijalkowski: > Is it *really* a security issue? We knew all along that dicts are > O(n^2) in worst case scenario, how is this suddenly a security > problem? For example Microsoft has released an extraordinary and unscheduled security patch for the issue between Christmas and New Year. I don't normally use MS as reference but this should give you a hint about the severity. Have you watched the talk yet? http://www.youtube.com/watch?v=R2Cq3CLI6H8 Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RNG in the core
> (or is /dev/urandom still available in a chroot?) Last time that I played with chroot, I "binded" /dev and /proc. Many programs rely on specific devices like /dev/null. Python should not refuse to start if /dev/urandom (or CryptoGen) is missing or cannot be used, but should use a weak fallback. Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Add a new PyUnicode_Fill() function
Oops, it's a typo in the doc (copy/paste failure). It's now fixed, thanks. Victor 2012/1/4 Antoine Pitrou : > >> +.. c:function:: int PyUnicode_Fill(PyObject *unicode, Py_ssize_t start, \ >> + Py_ssize_t length, Py_UCS4 fill_char) >> + >> + Fill a string with a character: write *fill_char* into >> + ``unicode[start:start+length]``. >> + >> + Fail if *fill_char* is bigger than the string maximum character, or if >> the >> + string has more than 1 reference. >> + >> + Return the number of written character, or return ``-1`` and raise an >> + exception on error. > > The return type should then be Py_ssize_t, not int. > > Regards > > Antoine. > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/victor.stinner%40haypocalc.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 7 clarification request: braces
On Wed, Jan 4, 2012 at 00:30, Stephen J. Turnbull wrote: > Benjamin Peterson writes: > > > My goodness, I was trying to make a ridiculous-sounding proposition. > > In this kind of discussion, that's in the same class as "be careful > what you wish for -- because you might just get it." I wish we could move onto better discussions than brace placement/existence at this point. *crosses fingers* ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Proposed PEP on concurrent programming support
(I've added back python-ideas, because I think that is still the appropriate forum.) > A new > suite type - the ``transaction`` will be added to the language. The > suite will have the semantics discussed above: modifying an object in > the suite will trigger creation of a thread-local shallow copy to be > used in the Transaction. Further modifications of the original will > cause all existing copies to be discarded and the transaction to be > restarted. ... How will you know that an object has been modified? The only ways I can think of are (1) Timestamp every object -- or at least every mutable object -- and hope that everybody agrees on which modifications should count. (2) Make two copies of every object you're using in the suite; at the end, compare one of them to both the original and the one you were operating on. With this solution, you can decide for youself what counts as a modification, but it still isn't straightforward; I would consider changing a value to be changing a dict, even though nothing in the item (header) itself changed. -jJ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RNG in the core
On Jan 04, 2012, at 02:59 AM, Antoine Pitrou wrote: >Well what if /dev/urandom is unavailable because the program is run >e.g. in a chroot? >(or is /dev/urandom still available in a chroot?) It is (apparently) in an schroot in Ubuntu, so I'd guess it's also available in Debian (untested). -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hash collision security issue (now public)
On Wed, Jan 4, 2012 at 12:59 AM, Maciej Fijalkowski wrote: > On Wed, Jan 4, 2012 at 12:02 AM, Bill Janssen wrote: >> Christian Heimes wrote: >> >>> Am 29.12.2011 12:13, schrieb Mark Shannon: >>> > The attack relies on being able to predict the hash value for a given >>> > string. Randomising the string hash function is quite straightforward. >>> > There is no need to change the dictionary code. >>> > >>> > A possible (*untested*) patch is attached. I'll leave it for those more >>> > familiar with unicodeobject.c to do properly. >>> >>> I'm worried that hash randomization of str is going to break 3rd party >>> software that rely on a stable hash across multiple Python instances. >>> Persistence layers like ZODB and cross interpreter communication >>> channels used by multiprocessing may (!) rely on the fact that the hash >>> of a string is fixed. >> >> Software that depends on an undefined hash function for synchronization >> and persistence deserves to break, IMO. There are plenty of >> well-defined hash functions available for this purpose. >> >> Bill >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/fijall%40gmail.com > > A lot of software will break their tests, because dict ordering would > depend on the particular run. I know, because some of them break on > pypy which has a different dict ordering. This is probably a good > thing in general, but is it really worth it? People will install > python 2.6.newest and stuff *will* break. So if we're making the new hashing the default and giving an option to use the old, we should make it _really_ clear in the release notes/announcement about how to revert the behavior. -eric > > Is it *really* a security issue? We knew all along that dicts are > O(n^2) in worst case scenario, how is this suddenly a security > problem? > > Cheers, > fijal > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ericsnowcurrently%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hash collision security issue (now public)
On Wed, Jan 04, 2012 at 11:55:13AM +0100, Antoine Pitrou wrote: > On Wed, 4 Jan 2012 09:59:15 +0200 > Maciej Fijalkowski wrote: > > > > Is it *really* a security issue? We knew all along that dicts are > > O(n^2) in worst case scenario, how is this suddenly a security > > problem? > > Because it has been shown to be exploitable for malicious purposes? I don't think that's news either. http://mail.python.org/pipermail/python-dev/2003-May/035907.html and http://twistedmatrix.com/pipermail/twisted-python/2003-June/004339.html for instance show that in 2003 it was clearly known to at least be likely to be an exploitable DoS in common code (a dict of HTTP headers or HTTP form keys). There was debate about whether it's the language's responsibility to mitigate the problem or if apps should use safer designs for handling untrusted input (e.g. limit the number of keys input is allowed to create, or use something other than dicts), and debate about just how practical an effective exploit would be. But I think it was understood to be a real concern 8 years ago, so not exactly sudden. Just because it's old news doesn't make it not a security problem, of course. -Andrew. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
