FileStorage Undo allows attacker to excecute arbitrary code

I dont have a complete understanding of the FileStorage Undo implementation yet, but I believe it allows anyone who has permission to perform an 'undo' to make arbitrary changes to the ZODB, and therefore execute arbitrary code inside the Zope process.

Filestorages Undo gives the through-the-web user a token which encodes transaction id and seek position of that transaction. The token is passed back to Zope to indicate which transactions are to be undone.

FileStorage uses the encoded seek position as an optimisation to avoid scanning the Data.fs a second time. For Transactional Undo It performs some sanity checking on that seek position; sufficient to detect accidental corruption of the token or an intermediate pack. If the sanity check fails, FileStorage uses the transaction id to find an accurate seek position by scanning back through the ZODB.

For old-style non-transactional-undo I can not see any sanity checking on the seek position.

An attacker can exploit this optimisation by inserting some carefully crafted data somewhere in Data.fs. This could be added as the content of a File object, DTMLMethod object, etc. This data needs to resemble a FileStorage transaction record, and contain the pickled objects which the attacker wants to insert into the ZODB.

The attacker then embeds the seek position of this record into a hand-crafted undo token, and passes it to FileStorage. FileStorage will proceed to copy the pickled objects from the body of the DTMLMethod into the ZODB as real objects.

I do not have a working exploit of this vulnerability.