Live data from Hacker News

Arbitrary file execution in TZinfo (Ruby)

github.com

21–30 of 30 posts

Re: Arbitrary file execution in TZinfo (Ruby)

#21
post #17

For everyone who is panicking about this - to be affected, you either need to use a really old version of tzinfo (0.3.60 and earlier), have the tzinfo-data gem installed, or explicitly set TZInfo::DataSource to DataSources::RubyDataSource. Otherwise, by default, tzinfo will use TZInfo::ZoneinfoDataSource, which does not seem to be affected. https://github.com/tzinfo/tzinfo/blob/d9b289e1be30d29a2cb23b... https://githu…

Versions 1.0.0 up to 1.2.9 are also vulnerable, not just the 0.x branch.

Edit: misread your comment, 1.x is vulnerable only if you have the tzinfo-data gem installed, or explicitly set TZInfo::DataSource to DataSources::RubyDataSource as you stated.

Re: Arbitrary file execution in TZinfo (Ruby)

#22

Earlier quoted context omitted.

Regex strikes again! I wonder how long it will take the computer industry to realise they just don't belong in code. Seems like most people still accept that they're hard to read and can't parse HTML but otherwise fine.

You're being downvoted and I agree that this is kind of overblown, but there is something here. This particular issue had nothing to do with readability specifically, but it had to do with the fact that the unpronounceable symbols ^ and $ had a specific meaning that was not what the devs expected. If we were using a more verbose pattern-matching DSL, we would probably have operators with names like "line_end" and "st…

I like regex too, but only for use in interactive contexts where you can verify the results (editors, search engines, etc). It's quite like Bash in that regard. Good for when you want to get a lot done without a lot of typing and you don't care if it only works on the input you have in front of you. A terrible idea everywhere else.

I also agree that more verbose syntax would help a lot. I've seen quite a few attempts to do that recently (e.g. the project formerly known as Rulex).

Re: Arbitrary file execution in TZinfo (Ruby)

#23

Earlier quoted context omitted.

You're being downvoted and I agree that this is kind of overblown, but there is something here. This particular issue had nothing to do with readability specifically, but it had to do with the fact that the unpronounceable symbols ^ and $ had a specific meaning that was not what the devs expected. If we were using a more verbose pattern-matching DSL, we would probably have operators with names like "line_end" and "st…

I like regex too, but only for use in interactive contexts where you can verify the results (editors, search engines, etc). It's quite like Bash in that regard. Good for when you want to get a lot done without a lot of typing and you don't care if it only works on the input you have in front of you. A terrible idea everywhere else. I also agree that more verbose syntax would help a lot. I've seen quite a few attempts…

Personally I use https://regex101.com to test and validate any nontrivial regex, and then I actually put a permalink to the "saved regex" in a comment in the code, so any future viewer (including myself) can review it. I also occasionally put patterns into their own standalone objects or functions (depending on the language), which allows you to test them right in your test suite.

I also make extensive use of the "verbose mode" in Python. Adapted from the example in https://docs.python.org/3/howto/regex.html, compare this:

    pattern = re.compile(r"^\s*&#(0[0-7]+|[0-9]+|x[0-9a-fA-F]+)\s*;\s*$")
and this one attempt to clean it up:

    pattern = re.compile(
        "^\s*"
        "&#("
        "0[0-7]+"
        "|[0-9]+"
        "|x[0-9a-fA-F]+"
        ")\s*;\s*$"
    )
to this:

    pattern = re.compile(r"""
      ^\s*
      &[#]                 # Start of a numeric entity reference
        (
            0[0-7]+        # Octal form
          | [0-9]+         # Decimal form
          | x[0-9a-fA-F]+  # Hexadecimal form
        )
      \s*;                 # Trailing semicolon
      \s*$
    """,
    re.VERBOSE)
It's still not ideal, but for me it's a good balance between terseness (greater information density) and readability.

The equivalent in Pomsky (I think this is the one that was formerly Rulex? https://pomsky-lang.org/) would be very similar:

    Start [s]*
    '&#'    # Start of a numeric entity reference
    (
      # Octal form
        '0' ['0' - '7']+
      # Decimal form
      | ['0' - '9']+
      # Hexadecimal form
      | 'x' ['0' - '9' 'a' - 'f' 'A' - 'F']+
    )
    [s]* ';'    # Trailing semicolon
    [s]* End
and arguably more verbose, due to the mandatory quotation marks. Note that Pomsky actually inherits the ambiguity of "Start" and "End" that led to this security bug in the first place!

Pomsky gets you a few other advantages, e.g. compatibility and polyfills across different regex engines, but the similar syntax I think goes to show how dramatic of an improvement "verbose regex" mode can be.

Finally, you have "English-like" DSLs more akin to my original suggestion, as in ReadableRegex.jl (https://github.com/jkrumbiegel/ReadableRegex.jl). I'm not sure how you'd construct the above pattern in that DSL, but I am sure that you would trade away information density and a sense of overall structure, and gain increased clarity of each individual operation. Set your priorities accordingly.

Re: Arbitrary file execution in TZinfo (Ruby)

#24
post #5

Do any Ruby devs have an idea about how widely exploitable this vulnerability is? The GitHub issue mentions that a file upload could trigger this. I'm guessing that's because the time zone is included in the "date modified" field, but that's just a hunch. If anybody is able to quickly spin up a Ruby on Rails app with a file uploader, I bet somebody be happy to bang on it and see if they can get an exploit to trigger.…

My read on the bug is that it'd take quite the combination of factors to be exposed, I don't think it poses a widespread or remotely likely risk.

App in question has to allow file upload that writes to local disk. Attacker would have to upload his ruby payload via this method.

App in question has to allow arbitrary, user-entered time zone select, eg allowing a user to enter "EST", and then pass that directly, raw, to TZInfo::Timezone.get(). Attacker would have to know where in the target filesystem their uploaded payload is, and submit a crafted timezone payload with escape characters to the path of their uploaded payload file relative to where the TZInfo gem is.

So, lets say I upload nasty_ruby.py, and the app puts it in /temp/myappuploads/nasty_ruby.py And lets say the tzinfo gem is running in /myapp/gems/tzinfo-gem/ I would submit something like 'fake\n../../../temp/myappuploads/nasty_ruby.py' which would cause the impacted tzinfo-gem method to call require on '../../../temp/myappuploads/nasty_ruby.py' which would execute it.

In general, I don't think I've ever seen time zone selection available as freeform text vs, say, a dropdown, so that seems fairly rare. Assuming you do have a freeform text form submission for timezone, you have to ALSO have a file upload capability that would place files on the local disk on the same system. And then, the attacker would have to either know or traverse/explore to find the path to where those files are on the system - ostensibly possible but seemingly unlikely? And this is all predicated on you using an old version of tzinfo-gem.

That said, if your ruby app checks all these boxes and is running an outdated version of the gem then yeah, its a straightforward RCE and thus very bad (and i think why they rated the severity as they did)

Re: Arbitrary file execution in TZinfo (Ruby)

#25

Earlier quoted context omitted.

I like regex too, but only for use in interactive contexts where you can verify the results (editors, search engines, etc). It's quite like Bash in that regard. Good for when you want to get a lot done without a lot of typing and you don't care if it only works on the input you have in front of you. A terrible idea everywhere else. I also agree that more verbose syntax would help a lot. I've seen quite a few attempts…

Personally I use https://regex101.com to test and validate any nontrivial regex, and then I actually put a permalink to the "saved regex" in a comment in the code, so any future viewer (including myself) can review it. I also occasionally put patterns into their own standalone objects or functions (depending on the language), which allows you to test them right in your test suite. I also make extensive use of the "ve…

Yeah the Pomsky one is already way better because you can easily see that &# are literal characters, not some weird regex thing you've forgotten about.

That's one of the biggest issues with regex - mixing up data and control.

But I would still expect a robust codebase to have a proper number parser if you want to parse this sort of thing.

Re: Arbitrary file execution in TZinfo (Ruby)

#26

Earlier quoted context omitted.

Regex strikes again! I wonder how long it will take the computer industry to realise they just don't belong in code. Seems like most people still accept that they're hard to read and can't parse HTML but otherwise fine.

You're being downvoted and I agree that this is kind of overblown, but there is something here. This particular issue had nothing to do with readability specifically, but it had to do with the fact that the unpronounceable symbols ^ and $ had a specific meaning that was not what the devs expected. If we were using a more verbose pattern-matching DSL, we would probably have operators with names like "line_end" and "st…

a better practice in ruby is to use the \A and \z anchors for beginning of string and end of string, ^ and $ are beginning and end of line in ruby as far as I know

Re: Arbitrary file execution in TZinfo (Ruby)

#27
post #5

Do any Ruby devs have an idea about how widely exploitable this vulnerability is? The GitHub issue mentions that a file upload could trigger this. I'm guessing that's because the time zone is included in the "date modified" field, but that's just a hunch. If anybody is able to quickly spin up a Ruby on Rails app with a file uploader, I bet somebody be happy to bang on it and see if they can get an exploit to trigger.…

My read on the bug is that it'd take quite the combination of factors to be exposed, I don't think it poses a widespread or remotely likely risk. App in question has to allow file upload that writes to local disk. Attacker would have to upload his ruby payload via this method. App in question has to allow arbitrary, user-entered time zone select, eg allowing a user to enter "EST", and then pass that directly, raw, to…

All good points, but FWIW re:

> I don't think I've ever seen time zone selection available as freeform text vs, say, a dropdown, so that seems fairly rare.

HTML dropdowns are freeform text when submitted.

This is sometimes interesting, and occasionally important.

Re: Arbitrary file execution in TZinfo (Ruby)

#28
post #27

Earlier quoted context omitted.

My read on the bug is that it'd take quite the combination of factors to be exposed, I don't think it poses a widespread or remotely likely risk. App in question has to allow file upload that writes to local disk. Attacker would have to upload his ruby payload via this method. App in question has to allow arbitrary, user-entered time zone select, eg allowing a user to enter "EST", and then pass that directly, raw, to…

All good points, but FWIW re: > I don't think I've ever seen time zone selection available as freeform text vs, say, a dropdown, so that seems fairly rare. HTML dropdowns are freeform text when submitted. This is sometimes interesting, and occasionally important.

that's an excellent point/callout.

Re: Arbitrary file execution in TZinfo (Ruby)

#30

Earlier quoted context omitted.

Personally I use https://regex101.com to test and validate any nontrivial regex, and then I actually put a permalink to the "saved regex" in a comment in the code, so any future viewer (including myself) can review it. I also occasionally put patterns into their own standalone objects or functions (depending on the language), which allows you to test them right in your test suite. I also make extensive use of the "ve…

Yeah the Pomsky one is already way better because you can easily see that &# are literal characters, not some weird regex thing you've forgotten about. That's one of the biggest issues with regex - mixing up data and control. But I would still expect a robust codebase to have a proper number parser if you want to parse this sort of thing.

What is regex but shorthand notation for a parser?

I agree that a good codebase should generally have its regex segregated into standalone functions with their own tests (ideally property-based tests!).

Post reply on HN