Commit graph

13 commits

Author SHA1 Message Date
Thom Smith
f20947ae25 Move code from lib3 to lib 2021-09-22 15:52:05 +02:00
Thom Smith
dc0c4c1441 Remove 2.7 support 2021-09-22 15:52:05 +02:00
Ovv
ddf20330be constructor.timezone: __copy_ & __deepcopy__
close #387
2021-01-13 16:58:40 -05:00
Ingy döt Net
a001f27825 Fix for CVE-2020-14343
Per suggestion https://github.com/yaml/pyyaml/issues/420#issuecomment-663888344
move a few constructors from full_load to unsafe_load.
2021-01-13 16:58:40 -05:00
Riccardo Schirone
5080ba5133
Prevents arbitrary code execution during python/object/new constructor (#386)
* Prevents arbitrary code execution during python/object/new constructor

In FullLoader python/object/new constructor, implemented by
construct_python_object_apply, has support for setting the state of a
deserialized instance through the set_python_instance_state method.
After setting the state, some operations are performed on the instance
to complete its initialization, however it is possible for an attacker
to set the instance' state in such a way that arbitrary code is executed
by the FullLoader.

This patch tries to block such attacks in FullLoader by preventing
set_python_instance_state from setting arbitrary properties. It
implements a blacklist that includes `extend` method (called by
construct_python_object_apply) and all special methods (e.g. __set__,
__setitem__, etc.).

Users who need special attributes being set in the state of a
deserialized object can still do it through the UnsafeLoader, which
however should not be used on untrusted input. Additionally, they can
subclass FullLoader and redefine `get_state_keys_blacklist()` to
extend/replace the list of blacklisted keys, passing the subclassed
loader to yaml.load.

* Make sure python/object/new constructor does not set some properties

* Add test to show how to subclass FullLoader with new blacklist
2020-03-17 19:09:55 +01:00
Tina Müller (tinita)
4fcdcdbf60 Add tests for timezone (#363)
After #163, this adds some test data to check if the datetime objects
return the correct timezone
2019-12-20 20:38:46 +01:00
Mattijs Ugen
96d65f3de1 Create timezone-aware datetimes when parsed as such (#163)
* On load, now use aware datetimes if possible

On loading data, if timestamps have an ISO "+HH:MM" UTC offset then the resultant datetime is converted to UTC.  This change adds that timezone information to the datetime objects.

Importantly, this addresses a Django warning (and potential error) that appears when using both YAML fixtures in a timezone-aware project.  It was raised as a Django issue (https://code.djangoproject.com/ticket/18867), but subsequently closed because the Django devs felt that this is a PyYAML problem.

* Create timezone-aware datetime in timezone from data

* Create timezone-aware datetime in timezone from data for python2

* Define better timezone implementation for python2

* Handle timezone "Z" for python 3

* Handle timezone "Z" for python 2

* Fix code structure for Python 3

Call datetime.datetime constructor once at return.

* Fix code structure for Python 2

Call datetime.datetime constructor once at return.
2019-12-20 20:38:46 +01:00
Tina Müller (tinita)
03b378d039
Allow add_multi_constructor with None (#358)
Loader.add_multi_constructor(None, myconstructor)

Also add test for add_multi_constructor('!', ...) etc.

See issue #317
2019-12-07 22:40:48 +01:00
Filip Salomonsson
5a0cfab86f Fix handling of __slots__ (#161) 2019-12-07 22:34:23 +01:00
David Kao
de11e43d52 fix typos and stylistic nit 2019-12-03 23:58:55 +01:00
Tina Müller
8c5e47fe62 Move constructor for object/apply to Unsafe 2019-11-20 20:48:47 +01:00
Ingy döt Net
0cedb2a069 Deprecate/warn usage of yaml.load(input)
The `load` and `load_all` methods will issue a warning when they are
called without the 'Loader=' parameter. The warning will point to a URL
that is always up to date with the latest information on the usage of
`load`.

There are several ways to stop the warning:

* Use `full_load(input)` - sugar for `yaml.load(input, FullLoader)`
  * FullLoader is the new safe but complete loader class
* Use `safe_load(input)` - sugar for `yaml.load(input, SafeLoader)`
  * Make sure your input YAML consists of the 'safe' subset
* Use `unsafe_load(input)` - sugar for `yaml.load(input, UnsafeLoader)`
  * Make sure your input YAML consists of the 'safe' subset
* Use `yaml.load(input, Loader=yaml.<loader>)`
  * Or shorter `yaml.load(input, yaml.<loader>)`
  * Where '<loader>' can be:
    * FullLoader - safe, complete Python YAML loading
    * SafeLoader - safe, partial Python YAML loading
    * UnsafeLoader - more explicit name for the old, unsafe 'Loader' class
* yaml.warnings({'YAMLLoadWarning': False})
  * Use this when you use third party modules that use `yaml.load(input)`
  * Only do this if input is trusted

The above `load()` expressions all have `load_all()` counterparts.

You can get the original unsafe behavior with:
* `yaml.unsafe_load(input)`
* `yaml.load(input, Loader=yaml.UnsafeLoader)`

In a future release, `yaml.load(input)` will raise an exception.

The new loader called FullLoader is almost entirely complete as
Loader/UnsafeLoader but it does it avoids all known code execution
paths. It is the preferred YAML loader, and the current default for
`yaml.load(input)` when you get the warning.

Here are some of the exploits that can be triggered with UnsafeLoader
but not with FullLoader:
```
python -c 'import os, yaml; yaml.full_load("!!python/object/new:os.system [echo EXPLOIT!]")'`
python -c 'import yaml; print yaml.full_load("!!python/object/new:abs [-5]")'
python -c 'import yaml; yaml.full_load("!!python/object/new:eval [exit(5)]")' ; echo $?
python -c 'import yaml; yaml.full_load("!!python/object/new:exit [5]")' ; echo $?
2019-03-08 09:09:48 -08:00
Pablo Santiago Blum de Aguiar
2c225b29fc scanner: use infinitive verb after auxiliary word could
Could, as well as should, shall, must, may, can, might, etc.
are auxiliary words. After an auxiliary word should come an
infinitive verb.
2015-04-04 13:25:24 -03:00