6 ms·

Arbitrary file execution in TZinfo (Ruby)

106 points by Ichaelus 4y ago

b0afc375b5 4y ago
Note that ruby: > Versions 2.0.0 and later are not vulnerable. Was about to panic there for a second. EDIT: Oops, I think I read it wrong, it's tzinfo version >2.0.0 that is not vulnerable, not ruby. Time to panic
vivo1817 4y ago
kitd 4y ago
Does anyone know if this uses ICU under the covers? Is that affected too?
- shakna 4y ago
  I don't believe that's the case, looking at the commit [0] [0] https://github.com/tzinfo/tzinfo/commit/01bcca5de920093b52fb871a19eb3eae86c9eaf2 https://github.com/tzinfo/tzinfo/commit/01bcca5de920093b52fb...
  - codedokode 4y ago
    Interesting. The reason for a bug seems to be that ^ and $ in regexps match a boundary of any line, not boundaries of a string. This have already caused problems in the past, as far as I remember, but Ruby developers didn't change the behaviour of these characters. So if you write a regexp like /^[0-9]$/, a string "Any characters\n12345\nAny characters" will match the regexp.
    - boygobbo 4y ago
      > Ruby developers didn't change the behaviour of these characters because Ruby has \A and \Z to match the boundaries of a string
deleted 4y ago
[deleted]
freeqaz 4y ago
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. (I'm headed to sleep now, but that will be a fun challenge to dig into tomorrow.) If this turns out to be something impactful and widespread, I'll tweet/blog[0] about it and give a shout out to anybody that helps on a POC. Raising awareness so that people are aware of RCE vectors like this one is important for making sure people update. (I'm guessing that somebody clever will figure out a "gadget-like" way to get RCE with this on a base Ruby install by loading in specific files from the disk. Ie, you will no longer need arbitrary file write access to the disk in order to turn this into RCE. That would scenario would make this CVE a much more widely exploitable attack, versus being fairly niche due to needing a more specific setup. I'm no Ruby expert, so maybe I'm totally wrong here.) 0: https://twitter.com/lunasecio https://twitter.com/lunasecio
- masklinn 4y ago
  > I'm guessing that's because the time zone is included in the "date modified" field, but that's just a hunch. From reading the description it looks like the second line, if present, is just (somehow) loaded as a ruby file. So this is exploitable on a file upload if you can find the destination location of the upload data. More generally if you can get a ruby script on the FS somehow, and this is accessible from the tzinfo-gem via a relative path, and you can probe the FS (but depending on the error feedback the vulnerability itself could provide the probing tool, if it lets you discriminate between EFILE and EEXIST… or if rails has a standard upload path and the average application will almost certainly be using that)
- deleted 4y ago
  [deleted]
- boesboes 4y ago
  Newer versions of tzinfo use non-ruby files for their data and are not effected afaict. My guess is that it might be exploitable when parsing a user provided datetime with zone without any sanitization of the input. And only when using that get method. I might try to see if Rails is vunerable to this, but probably not from a cursory glance
j16sdiz 4y ago
Is it really a bug in tzinfo? I think the bug is in the app that pass in user input as time zone
- codedokode 4y ago
  It is a bug in tzinfo. It should not execute random files when given invalid timezone identifier. The app doesn't know what is a "valid" or "invalid" timezone, it is tzinfo's responsibility to check it. UPD: in fact tzinfo tried to validate a timezone identifier but did it the wrong way. It used a regular expression like /^...$/ and using ^ and $ is a mistake here. This allows to bypass validation by passing a multiline identifier.
  - IshKebab 4y ago
    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.
    - nerdponx 4y ago
      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 "string_end", which don't require you to carefully cross-check the documentation in order to understand. Personally I love regex, but only because I'm good at it and I generally have a good memory for obscure trivia.
      - cesarb 4y ago
        > but it had to do with the fact that the unpronounceable symbols ^ and $ had a specific meaning that was not what the devs expected. What's worse is that ^ and $ have different meanings depending on whether you're using "single-line" or "multi-line" mode. From a quick web search, it seems Ruby always uses "multi-line" mode, while most other languages use "single-line" mode by default and have a flag to switch to "multi-line" mode. Someone who learned regex in other languages might not notice this difference, since most of the time the text being matched has no newlines, and so expect ^ and $ to match the boundaries of the text unless told otherwise by a "multi-line" flag.
zzem 4y ago
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/d9b289e1be30d29a2cb23bbfb6f4124a2692fd6d/lib/tzinfo/data_source.rb#L145 https://github.com/tzinfo/tzinfo/blob/d9b289e1be30d29a2cb23b... https://github.com/tzinfo/tzinfo/commit/b98c32efd61289fe6f00a50ab8061e95962ea983 https://github.com/tzinfo/tzinfo/commit/b98c32efd61289fe6f00...
- reyno 4y ago
  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.
752963e64 4y ago

106 points by Ichaelus 4y ago

Note that ruby: > Versions 2.0.0 and later are not vulnerable. Was about to panic there for a second. EDIT: Oops, I think I read it wrong, it's tzinfo version >2.0.0 that is not vulnerable, not ruby. Time to panic

vivo1817 4y ago

kitd 4y ago

Does anyone know if this uses ICU under the covers? Is that affected too?

shakna 4y ago
I don't believe that's the case, looking at the commit [0] [0] https://github.com/tzinfo/tzinfo/commit/01bcca5de920093b52fb871a19eb3eae86c9eaf2 https://github.com/tzinfo/tzinfo/commit/01bcca5de920093b52fb...
- codedokode 4y ago
  Interesting. The reason for a bug seems to be that ^ and $ in regexps match a boundary of any line, not boundaries of a string. This have already caused problems in the past, as far as I remember, but Ruby developers didn't change the behaviour of these characters. So if you write a regexp like /^[0-9]$/, a string "Any characters\n12345\nAny characters" will match the regexp.
  - boygobbo 4y ago
    > Ruby developers didn't change the behaviour of these characters because Ruby has \A and \Z to match the boundaries of a string

deleted 4y ago

[deleted]

freeqaz 4y ago

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. (I'm headed to sleep now, but that will be a fun challenge to dig into tomorrow.) If this turns out to be something impactful and widespread, I'll tweet/blog[0] about it and give a shout out to anybody that helps on a POC. Raising awareness so that people are aware of RCE vectors like this one is important for making sure people update. (I'm guessing that somebody clever will figure out a "gadget-like" way to get RCE with this on a base Ruby install by loading in specific files from the disk. Ie, you will no longer need arbitrary file write access to the disk in order to turn this into RCE. That would scenario would make this CVE a much more widely exploitable attack, versus being fairly niche due to needing a more specific setup. I'm no Ruby expert, so maybe I'm totally wrong here.) 0: https://twitter.com/lunasecio https://twitter.com/lunasecio

masklinn 4y ago
> I'm guessing that's because the time zone is included in the "date modified" field, but that's just a hunch. From reading the description it looks like the second line, if present, is just (somehow) loaded as a ruby file. So this is exploitable on a file upload if you can find the destination location of the upload data. More generally if you can get a ruby script on the FS somehow, and this is accessible from the tzinfo-gem via a relative path, and you can probe the FS (but depending on the error feedback the vulnerability itself could provide the probing tool, if it lets you discriminate between EFILE and EEXIST… or if rails has a standard upload path and the average application will almost certainly be using that)
deleted 4y ago
[deleted]
boesboes 4y ago
Newer versions of tzinfo use non-ruby files for their data and are not effected afaict. My guess is that it might be exploitable when parsing a user provided datetime with zone without any sanitization of the input. And only when using that get method. I might try to see if Rails is vunerable to this, but probably not from a cursory glance

j16sdiz 4y ago

Is it really a bug in tzinfo? I think the bug is in the app that pass in user input as time zone

codedokode 4y ago
It is a bug in tzinfo. It should not execute random files when given invalid timezone identifier. The app doesn't know what is a "valid" or "invalid" timezone, it is tzinfo's responsibility to check it. UPD: in fact tzinfo tried to validate a timezone identifier but did it the wrong way. It used a regular expression like /^...$/ and using ^ and $ is a mistake here. This allows to bypass validation by passing a multiline identifier.
- IshKebab 4y ago
  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.
  - nerdponx 4y ago
    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 "string_end", which don't require you to carefully cross-check the documentation in order to understand. Personally I love regex, but only because I'm good at it and I generally have a good memory for obscure trivia.
    - cesarb 4y ago
      > but it had to do with the fact that the unpronounceable symbols ^ and $ had a specific meaning that was not what the devs expected. What's worse is that ^ and $ have different meanings depending on whether you're using "single-line" or "multi-line" mode. From a quick web search, it seems Ruby always uses "multi-line" mode, while most other languages use "single-line" mode by default and have a flag to switch to "multi-line" mode. Someone who learned regex in other languages might not notice this difference, since most of the time the text being matched has no newlines, and so expect ^ and $ to match the boundaries of the text unless told otherwise by a "multi-line" flag.

zzem 4y ago

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/d9b289e1be30d29a2cb23bbfb6f4124a2692fd6d/lib/tzinfo/data_source.rb#L145 https://github.com/tzinfo/tzinfo/blob/d9b289e1be30d29a2cb23b... https://github.com/tzinfo/tzinfo/commit/b98c32efd61289fe6f00a50ab8061e95962ea983 https://github.com/tzinfo/tzinfo/commit/b98c32efd61289fe6f00...

reyno 4y ago
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.

752963e64 4y ago