Re: [Security-sig] Archives (.tar or .zip) with absolute paths

[Wes Turner]

CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path
Traversal')
https://cwe.mitre.org/top25/#CWE-22
http://cwe.mitre.org/data/definitions/22.html

- [ ] BUG,SEC: -P/--absolute-names

*13* *CWE-22 : Improper
Limitation of a Pathname to a Restricted Directory ('Path Traversal')*

CWE CATEGORY 21: Pathname Traversal and Equivalence Errors
https://cwe.mitre.org/data/definitions/21.html

https://cwe.mitre.org/data/definitions/21.html#Relationships ...

CWE 59: "Improper Link Resolution Before File Access ('Link Following')"
https://cwe.mitre.org/data/definitions/59.html

- [ ] ? BUG,SEC: symlinks?




Docs: https://docs.python.org/3/library/tarfile.html

- https://github.com/python/cpython/blob/2.6/Doc/library/tarfile.rst
- https://github.com/python/cpython/blob/3.6/Doc/library/tarfile.rst
- https://github.com/python/cpython/blob/master/Doc/library/tarfile.rst

Src: https://github.com/python/cpython/blob/master/Lib/tarfile.py

- https://github.com/python/cpython/blob/2.6/Lib/tarfile.py
- https://github.com/python/cpython/blob/3.6/Lib/tarfile.py


https://www.python.org/news/security/#reporting-security-issues-in-python

-
https://docs.python.org/devguide/documenting.html#security-considerations-and-other-concerns
  -
https://cpython-devguide.readthedocs.io/documenting.html#security-considerations-and-other-concerns
- [o] email to: secur...@python.org
  - [ ] Create an issue: https://bugs.python.org/
  - [ ] Create a pull request:
https://docs.python.org/devguide/pullrequest.html
- [ ] DOC:
- [ ] BUG,ENH,SEC: `python -m tarfile -P/--absolute-names`
- [ ] BUG,ENH,SEC: `python -m tarfile -h/--dereference
 --hard-dereference`
  - [ ] bandit test(s): https://github.com/openstack/bandit#writing-tests
- [ ] Python API
  - [ ]
- [ ] python -m tarfile
 - [ ] someone to lead on this because I am actually looking for a job

...

https://python-security.readthedocs.io/

- Src: https://github.com/haypo/python-security/blob/master/index.rst

- [ ] https://github.com/ebranca/owasp-pysec/wiki
- [ ]
https://github.com/ebranca/owasp-pysec/wiki/Security-Concerns-in-modules-and-functions




On Thu, Mar 9, 2017 at 11:37 AM, Victor Stinner 
wrote:

> Hi,
>
> I noticed that "python3 -m tarfile -x archive.tar" uses absolute paths
> by default, whereas the UNIX tar command doesn't by default. The UNIX
> tar command requires to add explicitly --absolute-paths (-P) option.
>
> The tarfile and zipfile modules (maybe also some others, I didn't
> check) contain warnings absolute paths and paths containing "..".
>
> Why not ignoring "/" at start of filenames *by default*? By backward
> compatibility?
>
> I suggest to add a boolean absolute_path option to tarfile and zipfile
> and disable it by default in the CLI. The question is what should be
> the default value for the Python API. I suggest to use
> absolute_path=False by default for safety.
>
>
> Example to create such archive. See that tar also removes "/" by
> default and requires to pass explicitly -P:
>
> $ cd $HOME
> # /home/haypo
> $ echo TEST > test
> $ tar -cf test.tar /home/haypo/test
> tar: Removing leading `/' from member names
>
> $ rm -f test.tar
> $ tar -P -cf test.tar /home/haypo/test
> $ rm -f test
>
>
> Extracting such archive using tar is safe *by default*:
>
> $ mkdir z
> $ cd z
> $ tar -xf ~/test.tar
> tar: Removing leading `/' from member names
> $ find
> .
> ./home
> ./home/haypo
> ./home/haypo/test
>
>
> Extracting such archive using Python is unsafe:
>
> $ python3 -m tarfile -e ~/test.tar
> $ cat ~/test
> TEST
> $ pwd
> /home/haypo/z
>
> Python creates files outside the current directory which is unsafe,
> wheras tar doesn't.
>
> Victor
> ___
> Security-SIG mailing list
> Security-SIG@python.org
> https://mail.python.org/mailman/listinfo/security-sig
>
___
Security-SIG mailing list
Security-SIG@python.org
https://mail.python.org/mailman/listinfo/security-sig

Re: [Security-sig] HTML page of Python security vulnerabilities

[Wes Turner]

2008-Present
http://www.cvedetails.com/product/18230/Python-Python.html?vendor_id=10210

There's a download link, but AFAICT not an API

On Friday, February 17, 2017, Victor Stinner 
wrote:

> Hi,
>
> I wrote a tool to generate an HTML report on Python security
> vulnerabilities. It takes the following YAML file as input:
> https://github.com/haypo/python-security/blob/master/vulnerabilities.yml
>
> And Python release dates, file written manually from Misc/NEWS:
> https://github.com/haypo/python-security/blob/master/python_releases.txt
>
> The output is the HTML page:
> http://python-security.readthedocs.io/en/latest/vulnerabilities.html
>
> For each vulnerability, you have a description and a list of links.
> From a list of commits, the tool computes the fixed Python and the
> number of days Python was vulnerable.
>
> Can you please check data of my two input files?
>
> What do you think of the page? Is it useful?
>
> TODO:
>
> * fix render_doc.py to support multiple lines in the table
> * add title to links
> * find the YAML syntax for "Issue #26657" :-) Current, #xxx is ignored
> since it's seen as a comment
> * maybe document in the YAML file how the Disclosure date was chosen
>
> Maybe I should add a "vulnerable" column to list Python versions which
> are vulnerable.
>
> If you consider the data useful and the data are double checked, the
> next step will to announce it.
>
> Later, I plan to slowly fill vulnerabilities.yml with recent
> vulnerabilities, and then with older vulnerabilities.
>
> FYI a few months ago, I generated the page manually, but quickly I
> realized that it's painful to compute all data and also to maintain
> manually such list. My old page:
> http://haypo-notes.readthedocs.io/python_security.html
>
> Victor
> ___
> Security-SIG mailing list
> Security-SIG@python.org 
> https://mail.python.org/mailman/listinfo/security-sig
>
___
Security-SIG mailing list
Security-SIG@python.org
https://mail.python.org/mailman/listinfo/security-sig

Re: [Security-sig] Unified TLS API for Python: Draft 3

[Wes Turner]

On Fri, Feb 10, 2017 at 11:22 AM, Cory Benfield <c...@lukasa.co.uk> wrote:

>
> On 10 Feb 2017, at 17:20, Wes Turner <wes.tur...@gmail.com> wrote:
>
> I learned about oscrypto:
>
> - oscrypto: "TLS (SSL) sockets, key generation, encryption, decryption,
> signing, verification and KDFs using the OS crypto libraries. Does not
> require a compiler, and relies on the OS for patching. Works on Windows, OS
> X and Linux/BSD."
>   - src: https://github.com/wbond/oscrypto
>   - pypi: https://pypi.python.org/pypi/oscrypto
>   - docs: https://github.com/wbond/oscrypto/blob/master/
> docs/readme.md#modern-cryptography
>
> Is oscrypto useful or relevant to this effort?
>
>
> You’ll note that the PEP credits Will Bond with review and oversight.
> oscrypto could absolutely be a backend that supports these APIs if Will
> wants it to be. =)
>

thanks!

docs:

- https://github.com/wbond/oscrypto/blob/master/docs/tls.md

src:

- https://github.com/wbond/oscrypto/blob/master/oscrypto/tls.py
- https://github.com/wbond/oscrypto/blob/master/oscrypto/_tls.py
-
https://github.com/wbond/oscrypto/blob/master/oscrypto/_linux_bsd/trust_list.py
- https://github.com/wbond/oscrypto/blob/master/oscrypto/_openssl/tls.py
- https://github.com/wbond/oscrypto/blob/master/oscrypto/_osx/tls.py
- https://github.com/wbond/oscrypto/blob/master/oscrypto/_win/tls.py

constants / enums

- _PROTOCOL_MAP
- https://github.com/wbond/oscrypto/blob/master/oscrypto/_cipher_suites.py
- https://github.com/tiran/tlsdb/blob/master/tlsdb.py > tlsdb.json
  - see: [ ] SChannel, [ ] Secure Transport tasks brainstormed above
- [ ] @IETF @W3C are there / should there be  URIs / URNs for these?


>
> Cory
>
>
___
Security-SIG mailing list
Security-SIG@python.org
https://mail.python.org/mailman/listinfo/security-sig

Re: [Security-sig] Unified TLS API for Python: Draft 3

[Wes Turner]

On Fri, Jan 27, 2017 at 9:30 AM, Wes Turner <wes.tur...@gmail.com> wrote:

>
>
> On Fri, Jan 27, 2017 at 3:10 AM, Cory Benfield <c...@lukasa.co.uk> wrote:
>
>>
>> On 26 Jan 2017, at 21:17, Donald Stufft <don...@stufft.io> wrote:
>>
>>
>> On Jan 26, 2017, at 4:18 AM, Cory Benfield <c...@lukasa.co.uk> wrote:
>>
>> For this reason I’m inclined to lean towards the more verbose approach of
>> just writing down what all of the cipher suites are in an enum. That way,
>> it gets much easier to validate what’s going on. There’s still no
>> requirement to actually support them all: an implementation is allowed to
>> quietly ignore any cipher suites it doesn’t support. But that can no longer
>> happen due to typos, because typos now cause AttributeErrors at runtime in
>> a way that is very obvious and clear.
>>
>>
>>
>> I’d say additionally that given the verbose approach a third party
>> library could provide this OpenSSL like API and be responsible for
>> “compiling” it down to the actual list of ciphers for input into the
>> verbose API. If one of those got popular and seemed stable enough to add
>> it, we could always add it in later as a higher level API for cipher
>> selection without the backends needing to change anything since the output
>> of such a function would still be a list of all of the desired ciphers
>> which would be the input to the backends.
>>
>>
>> Yup, strongly agreed.
>>
>
> https://github.com/tiran/tlsdb/blob/master/tlsdb.py
>
> - [ ] ENH: tlsdb.py: add parsers/datasources for {SChannel,
> SecureTransport}
>
>   - [x] openssl-master
>   - [x] openssl-1.02
>   - [x] gnutls-master
>   - [x] nss-tip
>   - [x] mod_nss-master
>   - [x] **iana**
>   - [x] mozilla-server-side
>   - [ ] SChannel
>   - [ ] SecureTransport
>
> - [ ] ENH: tlsdb.py: add OpenSSL-workalike lookup method
> - [ ] BLD: tls.config.__: generate Enums?
>

To be clear, I don't have the resources necessary to complete these tasks.
Would these tasks be necessary/helpful?

Reading:
https://github.com/mathiasertl/django-ca/blob/master/requirements.txt

I learned about oscrypto:

- oscrypto: "TLS (SSL) sockets, key generation, encryption, decryption,
signing, verification and KDFs using the OS crypto libraries. Does not
require a compiler, and relies on the OS for patching. Works on Windows, OS
X and Linux/BSD."
  - src: https://github.com/wbond/oscrypto
  - pypi: https://pypi.python.org/pypi/oscrypto
  - docs:
https://github.com/wbond/oscrypto/blob/master/docs/readme.md#modern-cryptography

Is oscrypto useful or relevant to this effort?


>
>>
>> Cory
>>
>> ___
>> Security-SIG mailing list
>> Security-SIG@python.org
>> https://mail.python.org/mailman/listinfo/security-sig
>>
>>
>
___
Security-SIG mailing list
Security-SIG@python.org
https://mail.python.org/mailman/listinfo/security-sig

Re: [Security-sig] Unified TLS API for Python: Draft 3

[Wes Turner]

On Fri, Jan 27, 2017 at 3:10 AM, Cory Benfield  wrote:

>
> On 26 Jan 2017, at 21:17, Donald Stufft  wrote:
>
>
> On Jan 26, 2017, at 4:18 AM, Cory Benfield  wrote:
>
> For this reason I’m inclined to lean towards the more verbose approach of
> just writing down what all of the cipher suites are in an enum. That way,
> it gets much easier to validate what’s going on. There’s still no
> requirement to actually support them all: an implementation is allowed to
> quietly ignore any cipher suites it doesn’t support. But that can no longer
> happen due to typos, because typos now cause AttributeErrors at runtime in
> a way that is very obvious and clear.
>
>
>
> I’d say additionally that given the verbose approach a third party library
> could provide this OpenSSL like API and be responsible for “compiling” it
> down to the actual list of ciphers for input into the verbose API. If one
> of those got popular and seemed stable enough to add it, we could always
> add it in later as a higher level API for cipher selection without the
> backends needing to change anything since the output of such a function
> would still be a list of all of the desired ciphers which would be the
> input to the backends.
>
>
> Yup, strongly agreed.
>

https://github.com/tiran/tlsdb/blob/master/tlsdb.py

- [ ] ENH: tlsdb.py: add parsers/datasources for {SChannel, SecureTransport}

  - [x] openssl-master
  - [x] openssl-1.02
  - [x] gnutls-master
  - [x] nss-tip
  - [x] mod_nss-master
  - [x] **iana**
  - [x] mozilla-server-side
  - [ ] SChannel
  - [ ] SecureTransport

- [ ] ENH: tlsdb.py: add OpenSSL-workalike lookup method
- [ ] BLD: tls.config.__: generate Enums?


>
> Cory
>
> ___
> Security-SIG mailing list
> Security-SIG@python.org
> https://mail.python.org/mailman/listinfo/security-sig
>
>
___
Security-SIG mailing list
Security-SIG@python.org
https://mail.python.org/mailman/listinfo/security-sig

Re: [Security-sig] Unified TLS API for Python

[Wes Turner]

On Thursday, January 12, 2017, Christian Heimes <christ...@cheimes.de>
wrote:

> On 2017-01-12 18:07, Wes Turner wrote:
> >
> >
> > On Thursday, January 12, 2017, Cory Benfield <c...@lukasa.co.uk
> <javascript:;>
> > <mailto:c...@lukasa.co.uk <javascript:;>>> wrote:
> >
> >
> >> On 11 Jan 2017, at 21:44, Wes Turner <wes.tur...@gmail.com
> <javascript:;>
> >> <javascript:_e(%7B%7D,'cvml','wes.tur...@gmail.com <javascript:;>');>>
> wrote:
> >>
> >> This may be a bit of a different use case (and possibly worth
> >> having in the first version of a new tls module):
> >>
> >> "Hitless TLS Certificate Rotation in Go"
> >> https://diogomonica.com/2017/01/11/hitless-tls-certificate-
> rotation-in-go/
> >> <https://diogomonica.com/2017/01/11/hitless-tls-certificate-
> rotation-in-go/>
> >>
> >> - Can/could this be done with only set_sni_callback ?
> >
> > Yes, it can be. Twisted has an extension module, txsni, that uses
> > the SNI callback to choose which certificate to provide.
> >
> >
> > https://github.com/glyph/txsni
> >
> >
> >  This is basically identical to the Go GetCertificate callback
> function.
> >
> >
> > There's more config than just the cert, though. There are really two
> > reqs mentioned: SNI (Server Name Indication), and "hot" TLS config
> > detection/selection:
> >
> > """
> > The idea is to allow an administrator to force the whole cluster to
> > migrate away from an old root CA transparently, removing its existence
> > from the trust stores of all the nodes participating in the Swarm. This
> > means that we need control over the whole TLS config, instead of
> > controlling only which certificate is currently being served.
> > """
> > '""
> > We chose to create a MutableTLSCreds
> > <https://github.com/docker/swarmkit/blob/master/ca/transport.go> struct,
> > which implements this TransportCredentials
> > <https://godoc.org/google.golang.org/grpc/credentials> interface and
> > allows the caller to simply change the TLS Config by
> > calling |LoadNewTLSConfig|.
> > """
> >
> > IIUC, we'd currently have to create a new context to change any config
> > other than the cert?
>
> Such advanced features are out-of-scope for the PEP. Please remember
> that any additional features makes it way more complicated for
> implementers. Personally I would rather remove half of the PEP than add
> new things. For pip, requests, and similar libraries only a subset of
> the features are really required:
>
> * ClientContext.wrap_socket()
> * a function like create_default_context() to create a client context
> that either loads a CA file or the system's trust store
> * TLSError
> * TLSWrappedSocket with socket.socket API
>
> Cory likes to define the API the additional features and server-side
> TLS. I consider it useful, partly advanced and nice-to-have, but not
> mandatory to solve the immediate issue we are facing now. [1]
>
> Let's keep it simple. We can always define an enhanced superset of the
> TLS ABC later. But we cannot remove features or change API in an
> incompatible way later.


I understand your scope concern.

In order to accomplish the aforementioned "hot" TLS config selection,
- Is there context-state to pass to TLSWrappedSocket.do_handshake(self,
[context/configurator])?
  - Or, would it be possible to specify injection so as to make subclassing
unnecessary?
  - Would it then be preferable to use a unified configuration object with
AttributeErrors and ValueErrors for the context (and any potential
connection-specific reconfigurations); instead of kwargs here and there?


>
> Christian
>
> https://mail.python.org/pipermail/distutils-sig/2017-January/029970.html
>
___
Security-SIG mailing list
Security-SIG@python.org
https://mail.python.org/mailman/listinfo/security-sig

Re: [Security-sig] Unified TLS API for Python

[Wes Turner]

On Thursday, January 12, 2017, Cory Benfield <c...@lukasa.co.uk> wrote:

>
> On 11 Jan 2017, at 21:44, Wes Turner <wes.tur...@gmail.com
> <javascript:_e(%7B%7D,'cvml','wes.tur...@gmail.com');>> wrote:
>
> This may be a bit of a different use case (and possibly worth having in
> the first version of a new tls module):
>
> "Hitless TLS Certificate Rotation in Go"
> https://diogomonica.com/2017/01/11/hitless-tls-certificate-rotation-in-go/
>
> - Can/could this be done with only set_sni_callback ?
>
>
> Yes, it can be. Twisted has an extension module, txsni, that uses the SNI
> callback to choose which certificate to provide.
>

https://github.com/glyph/txsni


>  This is basically identical to the Go GetCertificate callback function.
>

There's more config than just the cert, though. There are really two reqs
mentioned: SNI (Server Name Indication), and "hot" TLS config
detection/selection:

"""
The idea is to allow an administrator to force the whole cluster to migrate
away from an old root CA transparently, removing its existence from the
trust stores of all the nodes participating in the Swarm. This means that
we need control over the whole TLS config, instead of controlling only
which certificate is currently being served.
"""
'""
We chose to create a MutableTLSCreds
<https://github.com/docker/swarmkit/blob/master/ca/transport.go> struct,
which implements this TransportCredentials
<https://godoc.org/google.golang.org/grpc/credentials> interface and allows
the caller to simply change the TLS Config by calling LoadNewTLSConfig.
"""

IIUC, we'd currently have to create a new context to change any config
other than the cert?



>
> Cory
>
___
Security-SIG mailing list
Security-SIG@python.org
https://mail.python.org/mailman/listinfo/security-sig