[Python-Dev] Python possible vulnerabilities in concurrency

[Wes Turner]

CWE (Common Weakness Enumeration) has numbers (and URLs) and a graph model,
and code examples, and mitigations for bugs, vulnerabilities, faults,
design flaws, weaknesses.
https://cwe.mitre.org/

Research Concepts
https://cwe.mitre.org/data/definitions/1000.html

Development Concepts
https://cwe.mitre.org/data/definitions/699.html

CWE CATEGORY: Time and State
https://cwe.mitre.org/data/definitions/361.html

  CWE CATEGORY: Concurrency Issues
  https://cwe.mitre.org/data/definitions/557.html

17. Concurrent Execution
https://docs.python.org/3/library/concurrency.html


> 1. activating threads, tasks or pico-threads

https://docs.python.org/3/library/threading.html#threading.Thread.start
https://docs.python.org/3/library/threading.html#threading.Thread.run

> 2. Directed termination of threads, tasks or pico-threads

So, I looked this up:
https://stackoverflow.com/questions/323972/is-there-any-way-to-kill-a-thread-in-python

Do asynchronous programming patterns actually make this basically never
necessary? (asyncio coroutines, greenlet (eventlet, gevent, ), twisted)

https://docs.python.org/3/library/asyncio.html

https://docs.python.org/3/library/asyncio-task.html

If you really feel like you need the overhead of threads instead of or in
addition to coroutines (they won't use multiple cores without going to IPC,
anyway), you can.

> 3. Premature termination of threads, tasks or pico-threads

What is this referring to?
Does it release handles and locks on exception? (try/finally?)


> 4. Concurrent access to data shared between threads, tasks or
pico-threads,   and

CWE-362: Concurrent Execution using Shared Resource with Improper
Synchronization ('Race Condition')
https://cwe.mitre.org/data/definitions/362.html

CWE-567: Unsynchronized Access to Shared Data in a Multithreaded Context
https://cwe.mitre.org/data/definitions/567.html


> 5. Lock protocol errors for concurrent entities

CWE-667: Improper Locking
https://cwe.mitre.org/data/definitions/667.html

CWE-366: Race Condition within a Thread
https://cwe.mitre.org/data/definitions/366.html

The ``mutex`` module is removed in Python 3:
https://docs.python.org/2/library/mutex.html

17.1. threading — Thread-based parallelism
https://docs.python.org/3/library/threading.html


... Are there other good resources (in addition to Chapter 17) for
concurrency in CPython and/or PyPy and/or Stackless Python, MicroPython,
IronPython, Jython?

- [ ] How do we add Python to the excellent CWE reference?

- How can/could/should one add the things with labels (*) from the ISO PDF
you speak of to thr CWE graph? (* schema:name, rdfs:label)

On Wednesday, November 15, 2017, Guido van Rossum <guido at python.org> wrote:

> On Wed, Nov 15, 2017 at 6:50 PM, Guido van Rossum <guido at python.org
> <javascript:_e(%7B%7D,'cvml','guido at python.org');>> wrote:
>
>> On Wed, Nov 15, 2017 at 6:37 PM, Armin Rigo <armin.rigo at gmail.com
>> <javascript:_e(%7B%7D,'cvml','armin.rigo at gmail.com');>> wrote:
>>
>>> Hi,
>>>
>>> On 14 November 2017 at 14:55, Jan Claeys <lists at janc.be
>>> <javascript:_e(%7B%7D,'cvml','lists at janc.be');>> wrote:
>>> > Sounds like https://www.iso.org/standard/71094.html
>>> > which is updating https://www.iso.org/standard/61457.html
>>> > (which you can download from there if you search a bit; clearly either
>>> > ISO doesn't have a UI/UX "standard" or they aren't following it...)
>>>
>>> Just for completeness, I think that what you can download for free
>>> from that second page only contains the first few sections ("Terms and
>>> definitions").  It doesn't even go to "Purpose of this technical
>>> report"---we need to pay $200 just to learn what the purpose is...
>>>
>>> *Shrug*
>>>
>>
>> Actually it linked to http://standards.iso.org/ittf/
>> PubliclyAvailableStandards/index.html from which I managed to download
>> what looks like the complete c061457_ISO_IEC_TR_24772_2013.pdf (336
>> pages) after clicking on an "I accept" button (I didn't read what I
>> accepted :-). The $200 is for the printed copy I presume.
>>
>
> So far I learned one thing from the report. They use the term
> "vulnerabilities" liberally, defining it essentially as "bug":
>
> All programming languages contain constructs that are incompletely
>> specified, exhibit undefined behaviour, are implementation-dependent, or
>> are difficult to use correctly. The use of those constructs may therefore
>> give rise to *vulnerabilities*, as a result of which, software programs
>> can execute differently than intended by the writer.
>>
>
> They then go on to explain that sometimes vulnerabilities can be
> exploited, but I object to calling all bugs vulnerabilities -- that's just
> using a scary word to get attention for a sleep-inducing document
> containing such gems as "Use floating-point arithmetic only when absolutely
> needed" (page 230).
>
> --
> --Guido van Rossum (python.org/~guido)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171116/59262726/attachment.html>