Filippo ValsordaApr 17, 2024

A PSA since there's some confusion on this...

There is no vulnerability in Gorilla Sessions.

The vulnerability is in Palo Alto's internal SessDiskStore, which looks similar to FilesystemStore. Early analysis came to the mistaken conclusion that the vulnerable path was in FilesystemStore, but it's not. FilesystemStore authenticates the Session.ID with securecookie, SessDiskStore does not.

Show threadFilippo ValsordaApr 17, 2024

Hypothetically, if an application went out of their way to misuse FilesystemStore by not using its New API and stuffing attacker-controlled data in Session.ID (which is documented as not being safe), they could hit this.

That's *not* what happened to Palo Alto. They wrote their own Store that takes the session ID from a cookie in New without authentication.

Show threadMatt PalmerApr 17, 2024
@filippo between this and the "shell out to curl rather than use python's standard HTTP client" problem, it feels like Palo Alto has a real fetish for making things harder (and more insecure) than necessary.
Show threadRaven667Apr 17, 2024
@womble @filippo that comes from assigning junior engineers without adequate support with standards, code review and training which is created by management structure that prioritizes getting features out the door right now rather than right.
Show threadRaven667
@womble @filippo I can absolutely see a scenario where a dev prototypes something with curl and some basic shell scripting, then has to move on to the next task so just bakes that prototype into prod and declares victory. Not too sure about writing the session library, maybe unfamiliar with the code ecosystem and better ways to do it, leading to reimplantation...poorly
Apr 17, 2024 at 11:37pmWeb