[Python-Dev] Re: About vulnerabilities in Cpython native code

[Stephen J. Turnbull]

Chris Angelico writes:

 > Python source code is not user input though. So there has to be a way
 > for someone to attack a Python-based service, like attacking a web app
 > by sending HTTP requests to it.

Not sure what your point is.  Of course there has to be a vector.  But
as a Mailman developer, I can assure you that there are Python
programs facing the web that accept HTTP requests and SMTP messages,
and process the content, which could be anything an attacker wants it
to be.

I can't recall any CVEs that we could trace to Python (rather than our
code :-/), but Mailman can be and has been attacked.  I can imagine
that if there was an RCE vulnerability in Python or a C module we use,
Mailman would be a top candidate for a workable exploit because of the
amount of processing of user-supplied text we must do.  (Don't worry
about me, I sleep well anyway.  Python is pretty bullet-proof IMO ;-)

Did I completely misunderstand you, or the previous posters?

Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZMUQOAVBGYYNFDGQ3JIIRKXEAYXR6XAH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: About vulnerabilities in Cpython native code

[Chris Angelico]

On Fri, Jan 7, 2022 at 2:57 PM Stephen J. Turnbull
 wrote:
>
> Patrick Reader writes:
>
>  > And Python is not like JavaScript (in the browser), where code is
>  > supposed to be run in a total sandbox. Python is not supposed to be a
>  > completely memory-safe language. You can always access memory manually
>  > using `ctypes`, or, ultimately, `/proc/self/mem`.
>
> True enough, but
>
>  > For this reason, a buffer overflow in CPython is a bug because it can
>  > cause a crash, not because it can cause a security vulnerability.
>
> A crash *is* a (potential) security vulnerability.  If it can be
> reliably triggered by user input, it's a denial of service.
>

Python source code is not user input though. So there has to be a way
for someone to attack a Python-based service, like attacking a web app
by sending HTTP requests to it.

ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/4327CU63W745JGSQM4RO7M77F7BNXSUI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: About vulnerabilities in Cpython native code

[Stephen J. Turnbull]

Patrick Reader writes:

 > And Python is not like JavaScript (in the browser), where code is 
 > supposed to be run in a total sandbox. Python is not supposed to be a 
 > completely memory-safe language. You can always access memory manually 
 > using `ctypes`, or, ultimately, `/proc/self/mem`.

True enough, but

 > For this reason, a buffer overflow in CPython is a bug because it can 
 > cause a crash, not because it can cause a security vulnerability.

A crash *is* a (potential) security vulnerability.  If it can be
reliably triggered by user input, it's a denial of service.

Steve

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/6DLOXRJO6ZEIB7XDHYHBLHFYHG3MQIVS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Sanity check about ctypes

[Yonatan Zunger]

I think it makes good sense for the type-checking reason: _CData *does* declare
a fairly useful base interface that other classes also expose, so saying
that a function takes a _CData argument can make good sense. (As a bunch of
the methods in the io library do, for example) typeshed hacks it for the
case where one is using .pyi files for type annotations, but there's no
great way to just do that in ordinary Python code.

(Really, I think it would be lovely to stick proper type signatures
directly into the base libraries like io, but that's a whole separate
conversation. I like strong typing, does it show?)

Yonatan

On Wed, Jan 5, 2022 at 5:15 PM Gregory P. Smith  wrote:

>
> On Wed, Jan 5, 2022 at 3:17 PM Yonatan Zunger  wrote:
>
>> Hey everyone.
>>
>> Quick sanity check: The ctypes docs
>>  refer
>> to _CData as a non-public class which is in the module, but _ctypes.c doesn't
>> actually export it
>> .
>> (I discovered this because it turns out that typeshed *is* referencing
>> _CData, e.g. in its type annotations for RawIOBase
>> 
>> )
>>
>> Is this intended behavior in CPython (in which case the docs are a bit
>> off and typeshed has a bug), or is it unexpected to people on this list (in
>> which case it's an issue in _ctypes.c)?
>>
>
> typeshed is presumably referring to itself. It defines an interface for
> ctypes._CData in
> https://github.com/python/typeshed/blob/master/stdlib/ctypes/__init__.pyi#L82
>
> The CPython ctypes docs *seem* reasonable to me. There is such a class.
> It is not public, so you cannot access ctypes._CData in any direct manner.
> That it gets called a class may be somewhat historical - its purpose is to
> provide a common interface. What code would ever actually care that it used
> class mechanisms as an internal implementation detail to do that?
>
> -gps
>
>
>>
>> Yonatan
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/7L6DNNI3MJ4UIM3C7A7KAIWHX562MRZL/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/RFEECGPCUIYAWYIC7C4EFDR4JAH7I4MP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: About vulnerabilities in Cpython native code

[Eric V. Smith]

This is also at https://bugs.python.org/issue46280. Please direct 
comments there.


Eric

On 1/6/2022 8:22 AM, lxr1210--- via Python-Dev wrote:

Hi all,

I am currently doing some research on the security of CPython. I used 
the open source vulnerability analysis engine, 
Infer(https://fbinfer.com/), to scan the native code of CPython 3.10.0.


The scan results show that there are still a number of vulnerabilities 
in the CPython native code, such as Null dereference, Uninitialized 
variable, Resource/Memory leak, etc. Moreover, I found that some of 
the vulnerabilities are related to Python/C API. I enclose the 
vulnerability report for your reference.


Based on the research of the result, I tried to design a tool to 
automatically detect and repair vulnerabilities in CPython and make 
this tool available. See:


https://github.com/PVMPATCH/PVMPatch

Python is my favourite programming language. I sincerely hope that I 
can help Python become stronger and safer. I hope this discovery can 
be useful for you to develop Python in the future.


Thank you for your time and consideration!



Lin


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WQ2TVXPWFWP7V34WOGL2IDSDNAUQGEJU/
Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5BJNES7RVFLMLA2KJHSVF6AXMHLLQGSP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: About vulnerabilities in Cpython native code

[Patrick Reader]

On 06/01/2022 15:21, Petr Viktorin wrote:
Sometimes there's a bug worth fixing, sometimes it's even an actual 
vulnerability, but in my experience, most of what tools find in 
CPython is not actionable.


If you do find a security vulnerability, consider reporting it 
privately to the security team: see https://www.python.org/dev/security/


And Python is not like JavaScript (in the browser), where code is 
supposed to be run in a total sandbox. Python is not supposed to be a 
completely memory-safe language. You can always access memory manually 
using `ctypes`, or, ultimately, `/proc/self/mem`.


For this reason, a buffer overflow in CPython is a bug because it can 
cause a crash, not because it can cause a security vulnerability.


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PLYRO6VSFNHIRD5FMSEK5RTZJNMTQG7G/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: About vulnerabilities in Cpython native code

[Petr Viktorin]

On 06. 01. 22 14:22, lxr1210--- via Python-Dev wrote:

Hi all,

I am currently doing some research on the security of CPython. I used 
the open source vulnerability analysis engine, 
Infer(https://fbinfer.com/), to scan the native code of CPython 3.10.0.


The scan results show that there are still a number of vulnerabilities 
in the CPython native code, such as Null dereference, Uninitialized 
variable, Resource/Memory leak, etc. Moreover, I found that some of the 
vulnerabilities are related to Python/C API. I enclose the vulnerability 
report for your reference.


The first page of these looks like false positives (except one might be 
a flaw in test code).
But that's par for the course. I've spent a lot of time digging through 
reports like these. Sometimes there's a bug worth fixing, sometimes it's 
even an actual vulnerability, but in my experience, most of what tools 
find in CPython is not actionable.


If you do find a security vulnerability, consider reporting it privately 
to the security team: see https://www.python.org/dev/security/



Based on the research of the result, I tried to design a tool to 
automatically detect and repair vulnerabilities in CPython and make this 
tool available. See:


https://github.com/PVMPATCH/PVMPatch

Python is my favourite programming language. I sincerely hope that I can 
help Python become stronger and safer. I hope this discovery can be 
useful for you to develop Python in the future.


Thank you for your time and consideration!



___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PRDD4CROYQFER3J3YYIKEAK5KHQECKHR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: About vulnerabilities in Cpython native code

[Chris Angelico]

On Fri, Jan 7, 2022 at 1:59 AM lxr1210--- via Python-Dev
 wrote:
>
> Hi all,
>
> I am currently doing some research on the security of CPython. I used the 
> open source vulnerability analysis engine, Infer(https://fbinfer.com/), to 
> scan the native code of CPython 3.10.0.
>
> The scan results show that there are still a number of vulnerabilities in the 
> CPython native code, such as Null dereference, Uninitialized variable, 
> Resource/Memory leak, etc. Moreover, I found that some of the vulnerabilities 
> are related to Python/C API. I enclose the vulnerability report for your 
> reference.
>

Tool needs some improvements.

Py_CLEAR is documented as doing nothing if given a null pointer.

All of the "value not used" complaints seem to be places where
something is coded in a consistent way, such as repeatedly
incrementing a value and comparing it to something, so it would be a
code maintenance hassle to do things differently on the last one.

I checked a few of the null dereference complaints. The tool seems
concerned that PyUnicode_DATA(str) might return NULL, that
assert(state != NULL) won't stop the function, and that
PyThreadState_Get might return NULL (it's documented as bombing with a
fatal error in such a situation, so you specifically don't have to
check).

The complaint about unicodedata.c line 168 is a bit subtler, but the
tool isn't able to recognize that rc is always initialized (either
have_old will be set and rc is set, or if have_old isn't set, then rc
will be set).

It would make validation a LOT easier if the complaints could be grouped.

ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/KIM5KZIFEFQK7VZT3ZF2WTPLCAYOGQI6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [python-committers] Re: Python 3.11.0a4 is blocked

[Victor Stinner]

On Thu, Jan 6, 2022 at 12:33 PM Pablo Galindo Salgado
 wrote:
> * https://bugs.python.org/issue46006
>
> Victor made a revert of his PR but unfortunately, we cannot easily backport 
> it to 3.10 as it affects the ABI. It affects the interpreter state structure 
> that although is not on the stable ABI, changing it can affect some projects 
> so we need to discuss how we want to proceed as a project here.

Well, the regression is fixed in the main branch, so Python 3.11.0a4
should be unblocked for this issue.

I updated my backport to 3.10 to fix the ABI issue.

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/MD6T6CS4X3677GQOYDHLKDRNUXPQ2JEU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python 3.11.0a4 is blocked

[Pablo Galindo Salgado]

Hi everyone,

An update on this. Unfortunately, we are still blocked. Some of the
blockers have been fixed (thanks to everyone involved) but the following
are still pending:

* https://bugs.python.org/issue46208

This issue has a PR being reviewed but the fix is still not merged.

* https://bugs.python.org/issue46006

Victor made a revert of his PR but unfortunately, we cannot easily backport
it to 3.10 as it affects the ABI. It affects the interpreter state
structure that although is not on the stable ABI, changing it can affect
some projects so we need to discuss how we want to proceed as a project
here.

* https://bugs.python.org/issue46263

One of the FreeBSD issues has been fixed (thanks Christian) but another
issue has been unveiled (some problem in test_capi) and the other one still
lingers (test_embed failing due to freezing modules).

Thanks for all your help,

Kind regards from cloudy London,
Pablo Galindo Salgado


On Tue, 4 Jan 2022 at 23:12, Pablo Galindo Salgado 
wrote:

> Hi everyone,
>
> I am writing this to notify you that unfortunately the release of 3.11.0a4
> is blocked as there are a bunch of release blockers
> (some of them affect Python 3.10):
>
> https://bugs.python.org/issue46263
> https://bugs.python.org/issue46208
> https://bugs.python.org/issue46006
> https://bugs.python.org/issue43683
>
> If this was a single release blocker I would think about moving
> forward but unfortunately, there are several of them and one of
> them is that Python fails to compile FreeBSD, so I am halting the release
> until these are fixed.
>
> Regards from rainy London,
> Pablo Galindo Salgado
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/UCGWU4VTU6YM63CQKMBROVEYOGW6CKWR/
Code of Conduct: http://python.org/psf/codeofconduct/