[issue8678] crashers in rgbimg
Tomas Hoger added the comment: You seem to be right that r65878 should block the "xsize = ysize = 0x8000" integer overflow. I was testing on the python version with r60793, but not with r65878. Note that the check added in r65878 should still cause crash on divide-by-zero for some files. Attaching my test files. 1 is for excessive ZSIZE, 2 and 3 for the integer overflow, RLE and non-RLE code path, 4 and 5 for RLE decoding issues. 6 should trigger sigfpe in the r65878 check as noted above, but I've not really tested that one. -- Added file: http://bugs.python.org/file19417/rgbimg-issue8678.tgz ___ Python tracker <http://bugs.python.org/issue8678> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5753] CVE-2008-5983 python: untrusted python modules search path
Tomas Hoger added the comment: Has anyone else had an opportunity to have a look at the change proposed in #msg90336? -- ___ Python tracker <http://bugs.python.org/issue5753> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5753] CVE-2008-5983 python: untrusted python modules search path
Tomas Hoger added the comment: Can anyone move this to Stage: patch review (for the fix approach proposed in msg90336)? Or does anyone have better idea on how to move this closer to final fix or wontfix / reject? Thank you! -- ___ Python tracker <http://bugs.python.org/issue5753> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8674] audioop: incorrect integer overflow checks
New submission from Tomas Hoger : SVN commit r64114 added integer overflow checks to multiple modules. Checks added to audioop module are incorrect and can still be bypassed: http://svn.python.org/view/python/trunk/Modules/audioop.c?r1=64114&r2=64113 - audioop_tostereo - should be fine, but relies on undefined behaviour - audioop_lin2lin - undetected overflow: size=1, size2=4, len=0x4001 - audioop_ratecv - undetected overflow: nchannels=0x5fff (32bit) - audioop_ulaw2lin - undetected overflow: size=4, len=0x4001 - audioop_alaw2lin - same as audioop_ulaw2lin - audioop_adpcm2lin - undetected overflow: size=4, len=0x2001 Most of these are triggered by large fragment as an input. Attached patch replaces checks added in r64114 by checks using INT_MAX. -- components: Extension Modules files: python2.6-audioop-int-overflows.diff keywords: patch messages: 105434 nosy: thoger priority: normal severity: normal status: open title: audioop: incorrect integer overflow checks type: security versions: Python 2.6 Added file: http://bugs.python.org/file17281/python2.6-audioop-int-overflows.diff ___ Python tracker <http://bugs.python.org/issue8674> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8674] audioop: incorrect integer overflow checks
Tomas Hoger added the comment:
> Do you have any Python examples that failed to trigger the overflow
> on your platform?
No, I've not really tried to create some, as I found it while looking into
similar checks added to rgbimg module (which is dead and removed upstream now)
in the same commit r64114.
Having another close look, I can reproduce crash with lin2lin:
audioop.lin2lin("A"*0x4001, 1, 4)
ratecv may cause issues too. Other cases use for loop with multiplication
product as an upper bound, so the integer overflow should be harmless in those
case.
> is there something about the formats that audioop is dealing
> with that limits sizes to INT_MAX (rather than PY_SSIZE_T_MAX,
> for example)?
I've started looking into this on oldish python 2.4, where
PyString_FromStringAndSize accepts int size, rather than Py_ssize_t. Rest of
the audioop code was using ints too. It's possible it is ok to more to size_t
in current python version.
--
___
Python tracker
<http://bugs.python.org/issue8674>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8678] crashers in rgbimg
Tomas Hoger added the comment: According to PEP-0004, affected module was deprecated in 2.5 and is no longer part of 2.6 and later. Hence 2.5 only, not sure if that version is still actively supported upstream. -- nosy: +thoger versions: -Python 2.6, Python 2.7 ___ Python tracker <http://bugs.python.org/issue8678> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13885] CVE-2011-3389: _ssl module always disables the CBC IV attack countermeasure
Tomas Hoger added the comment: Is the final patch going to enable empty fragments unconditionally and will ofter no way to disable them? curl did that recently and ended up adding option to allow users to disable empty fragments when they break compatibility: http://curl.haxx.se/docs/adv_20120124B.html http://thread.gmane.org/gmane.comp.web.curl.library/34659 http://curl.haxx.se/libcurl/c/curl_easy_setopt.html#CURLOPTSSLOPTIONS http://curl.haxx.se/docs/manpage.html#--ssl-allow-beast -- nosy: +thoger ___ Python tracker <http://bugs.python.org/issue13885> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5753] CVE-2008-5983 python: untrusted python modules search path
Tomas Hoger added the comment:
Have you considered something like this? (patch against 3.1)
--- Python/sysmodule.c.orig
+++ Python/sysmodule.c
@@ -1643,6 +1643,7 @@ PySys_SetArgv(int argc, wchar_t **argv)
#endif /* Unix */
}
#endif /* All others */
+ if (n > 0 || argv0 == NULL || wcscmp(argv0, L"-c") == 0) {
a = PyUnicode_FromWideChar(argv0, n);
if (a == NULL)
Py_FatalError("no mem for sys.path insertion");
@@ -1650,6 +1651,7 @@ PySys_SetArgv(int argc, wchar_t **argv)
Py_FatalError("sys.path.insert(0) failed");
Py_DECREF(a);
+ }
}
Py_DECREF(av);
}
I presume main problem here is that '' may end up as first item in
sys.path in certain cases.
That is desired in some cases, namely:
- python run in interactive mode
- python -c '...'
It does not happen and is not desired in other cases:
- ./foo.py
- python foo.py
- env python foo.py
Here foo.py can be just filename or filename with relative or absolute
path. In all these cases python seems to set argv0 to something
realpath can resolve.
Problematic case is embedded use when bogus argv0 can cause '' to be
added to sys.path, but it's usually not desired / expected (is anyone
aware of the case when that is expected?). It can be argued whether
apps should use garbage as argv0, but example in Demo/embed/demo.c do it
as well...
Patch above attempts to skip modification of sys.path when realpath
failed (n == 0). There are two special cases, that are treated as
special on couple of other places in PySys_SetArgv already:
- argv0 == NULL (interactive python)
- argv0 == "-c" (python -c)
This should fix the problem for apps embedding python and providing
garbage argv0. It would not make a difference for apps that provide
some valid path as argv0. I'm not aware of non-embedded python use that
will end up with different sys.path after this patch.
Ideas? Anyone is aware of the valid usecase that can break with this?
Advantage to Ex approach is that it does not require change on the
embedding apps side, and should really impact only those setting garbage
argv0.
--
nosy: +thoger
___
Python tracker
<http://bugs.python.org/issue5753>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5753] CVE-2008-5983 python: untrusted python modules search path
Tomas Hoger added the comment: Additional API has one disadvantage - it requires a modification of all affected applications embedding python, which is not likely to happen soon after the API is introduced. Therefore, it may still be worth reviewing current behaviour (that seemed to have had no documentation until recently, see issue #5144, and can probably still benefit from more warnings related to the embedded use) in this corner case (argv0 is bogus and contains no '/') to see if it may be worth changing in future python versions. As for command line flags, I presume you're referring to the 'wcscmp(argv0, L"-c")' part of the patch. It's not more than a re-use of the pattern already used couple of times in the PySys_SetArgv, that got added via: http://svn.python.org/view?view=rev&revision=39544 Again, it's an attempt to make sure this only changes behaviour in rather specific case. -- ___ Python tracker <http://bugs.python.org/issue5753> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5753] CVE-2008-5983 python: untrusted python modules search path
Tomas Hoger added the comment:
This is not really the same thing as issue 946373. That one seems to be
about adding script's directory as the first thing in sys.path.
Comments there seem to mix both interactive ('' in sys.path) and
non-interactive (os.path.dirname(os.path.abspath(sys.argv[0])) in
sys.path) python uses, while CVE-2008-5983 is only about '' in sys.path,
mostly related to embedded use, rather than for python interpreter itself.
--
___
Python tracker
<http://bugs.python.org/issue5753>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5753] CVE-2008-5983 python: untrusted python modules search path
Tomas Hoger added the comment:
> My reading of PySys_SetArgv is that if argv is NULL, then
> "char *argv0 = argv[0];" will read through NULL and thus will
> segfault on a typical platform.
Right.
> I favor Antoine's approach in
> http://bugs.python.org/file13860/setargvex.patch of adding a new API
> entry point, whilst maximizing compatibilty for all of the code our
> there using the existing entry point.
Sadly, this won't help existing applications affected by this problem, without
all of them needing to be changed.
My change proposed in msg90336 won't help either, at least not in all cases.
Apps that call PySys_SetArgv with 1, { "myappname", NULL } can still be tricked
to add full CWD path at the beginning of sys.path on platforms with realpath().
--
___
Python tracker
<http://bugs.python.org/issue5753>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5753] CVE-2008-5983 python: untrusted python modules search path
Tomas Hoger added the comment:
+ - If the name of an existing script is passed in ``argv[0]``, its absolute
+ path is prepended to :data:`sys.path`
Absolute path to the directory where script is located. And I believe there's
no absolute path guarantee for platforms without realpath / GetFullPathName.
Should the documentation also give some guidance to those that embed python and
don't want to start using SetArgvEx right away and break compatibility with
older python versions? Something like:
If you're embedding python in your application, using SetArgv and don't want
modified sys.path, call PyRun_SimpleString("sys.path.pop(0)\n"); after SysArgv
to unconditionally drop the first sys.path argument added by SetArgv.
--
___
Python tracker
<http://bugs.python.org/issue5753>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
