This was originally logged as a private issue to the security team, but was cleared to be moved to the public queue
The field sql storage (like the cache layer) has an unrestricted unserialize() call.
In
https://www.drupal.org/project/drupal/issues/2232427
📌
Allow field types to control how properties are mapped to and from storage
Needs work
the question arose if can lead to another instance of SA-CORE-2019-003 which is about api-injected evil data (but i'm not familiar with the internal details of that one).
Some research:
- Core uses serialized storage of objects in section storage (see
https://www.drupal.org/project/drupal/issues/3484469
📌
Do not store sections as PHP objects
Active
).
- Custom code may use that too (i'm doing it a lot)
- The unserialize() is in \Drupal\Core\Entity\Sql\SqlContentEntityStorage::mapFromStorageRecords
- Mitigation: As i grok it, an attack can only happen if evil data passes through the (core / custom) FieldItem class and is written to DB.
More eyes needed:
- Some more eyes please cross-check the claim "an attack can only happen if evil data passes through the (core / custom) FieldItem class and is written to DB." as that is fundamental to all the following.
- add a warning to the 'serialize' property for field item storage in FieldItemInterface::schema, sth like "If 'serialize' is used, the FieldItem class is responsible to prevent storage of evil classes, via ::setValue or custom TypedData class"
- add a allowedClasses whitelist to 'serialize' and deprecate usage without it.
- add comments to all unresticted serialize() calls and possibly add a code style rule to guard that.
List of people initially involved and should receive credit here:
bradjones1
bramdriesen
mcdruid
benjifisher
greggles
geek-merlin
Active
11.0 🔥
entity system
It is used for security vulnerabilities which do not need a security advisory. For example, security issues in projects which do not have security advisory coverage, or forward-porting a change already disclosed in a security advisory. See Drupal’s security advisory policy for details. Be careful publicly disclosing security vulnerabilities! Use the “Report a security vulnerability” link in the project page’s sidebar. See how to report a security issue for details.
The title of this issue refers to "Field sql storage", and the proposed resolution mentions Drupal\Core\Field\FieldItemInterface::schema(). But
📌
Allow field types to control how properties are mapped to and from storage
Needs work
refers to \Drupal\Core\Entity\Sql\SqlContentEntityStorage, and I think that is where the actual calls to unserialize() are.