39 pointsby pentestercrab5 hours ago5 comments
  • Nextgrid3 hours ago
    Doesn't this already require to be "on the other side of the airtight hatchway", or am I missing something?

    The Marshal.load docs explicitly have a warning that you should not pass it untrusted data: https://docs.ruby-lang.org/en/master/Marshal.html#module-mar...

    • Retr0id3 hours ago
      Yes, but that doesn't mean defense-in-depth isn't worth doing. The article discusses how known gadgets were removed in the past.
  • sebiw3 hours ago
    Which brings us to the old saying: Do not deserialize untrusted data.

    In the context of Rubygems and their specs this obviously is harder to manage but dependencies such as Rubygems are and will always be part of your app's Trusted Computing Base.

    • sscaryterry2 hours ago
      > dependencies such as Rubygems are and will always be part of your app's Trusted Computing Base

      This mindset is changing, in the npm ecosystem, managing and updating dependencies have become somewhat of a gamble. It is no longer if, its when you are compromised.

    • wyageran hour ago
      > Do not deserialize untrusted data.

      I think the better lesson is "use safe codecs"

    • ares62334 minutes ago
      LLMs: hold my beer
  • shevy-java24 minutes ago
    That's actually crafty. I wonder what the rationale was for the C function time_mload(). Anyone able to find out? How can we see which person created it first?
  • mono442an hour ago
    Quoting the ruby documentation:

    > Marshal.load is not suitable as a general purpose serialization format and you should never unmarshal user supplied input or other untrusted data.

  • saadyousfi2 hours ago
    [dead]