←back to thread

Public secrets exposure leads to supply chain attack on GitHub CodeQL

(www.praetorian.com)
297 points cyberbender | 1 comments | 30 Mar 25 19:54 UTC | HN request time: 2.834s | source
Show context
nyrikki ◴[30 Mar 25 21:51 UTC] No.43528008[source]▶
No mention why this temp token had rights to do things like create a new deployments and generate artifact attestations?

For their fix, they disabled debug logs...but didn't answer if they changed the temp tokens permissions to something more appropriate for a code analysis engine.

replies(6): >>43528290 #>>43531049 #>>43533461 #>>43538343 #>>43538350 #>>43545199 #
declan_roberts ◴[30 Mar 25 22:21 UTC] No.43528290[source]▶
I think we all know this old story. The engineer building it was getting permission denied so they gave it all the permissions and never came back and right-sized.
replies(2): >>43528378 #>>43528414 #
setr ◴[30 Mar 25 22:36 UTC] No.43528414[source]▶
Does any RBAC system actually tell you the missing permissions required to access the object in question? It’s like they’re designed to create this behavior
replies(4): >>43528495 #>>43528507 #>>43529353 #>>43534107 #
1. Uvix ◴[31 Mar 25 12:17 UTC] No.43534107[source]▶
Azure’s RBAC system usually tells you this, at least when accessing the Azure management APIs. (Other APIs using RBAC, like the Azure Storage or Key Vailt ones, usually aren’t so accommodating. At least by their nature there’s usually only a handful of possible permissions to choose from.)