b33f | 🇺🇦✊'s banner
b33f | 🇺🇦✊'s profile picture

b33f | 🇺🇦✊

@FuzzySec • 33,560 subscribers

意志 / mobile research @ ▓▓▓▓▓ / Team 501 / ex IBM Capability Lead & FireEye TORE / I rewrite pointers and read memory / AI Psychoanalyst / BHUSA Review Board

Videos

FuzzySec's profile picture

I wanted to understand this ruby issue in a bit more detail. Here is what actually happened. The AI posts a gem to RubyGems containing a .yardopts file. RubyGems only stores and distributes this gem, no code execution happens. RubyDoc (a separate service) then retrieves and unpacks the gem to create and publish API documentation (using YARD). YARD automatically parses the .yardopts file and because it is not configured safely it eventually executes a "--load" argument granting arbitrary code execution in the RubyDoc worker container (as that worker). At that point it can do anything in the container (accessing the file system, manipulating any data or credential material that may exist, network traffic, etc). I've been on the internet for a long time, the curious thing to me is that this is only possible because YARD runs in non-safe mode (as a configuration). How is it possible that this is true, we live on the internet people must have abused this before? It turns out they did, in 2012 they enabled safe mode in this commit to prevent this exact issue: But, in 2019, when they dockerized they removed the safe flag: I guess it's a regression. That means since 2019, you could have had free containers through RubyGems, pretty sloppy work fr. I wouldn't be surprised if this has been used ITW for some years by more careful humans. It also makes sense as a target, granular control over gems that feed back into the sandbox package proxy are a good way to expand the attack surface internally. A quick POC then ✌️

b33f | 🇺🇦✊

17,194 Aufrufe • vor 1 Monat

Keine weiteren Inhalte verfügbar