Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Heap Overflow in Floating Point Parsing (CVE-2013-4164)

ruby-lang.org

Post reply on HN
Print view View original

1–10 of 18 posts

Re: Heap Overflow in Floating Point Parsing (CVE-2013-4164)

#5

Post by asdfaoeu »

yuhong wrote: post #3
asdfaoeu wrote: post #2

Strikes me as a bit silly not to patch this in 1.8 considering it's still fairly widely used and even the default for Ubuntu 12.04 LTS.

https://www.ruby-lang.org/en/news/2013/06/30/we-retire-1-8-7...

I can read too, announced here https://www.ruby-lang.org/en/news/2011/10/06/plans-for-1-8-7... . However I do think discontinuing security updates after 2 years announcement for a product that even they say is "more or less" used by everyone isn't the best decision.

Re: Heap Overflow in Floating Point Parsing (CVE-2013-4164)

#7

Post by lloeki »

asdfaoeu wrote: post #5
yuhong wrote: post #3

Earlier quoted context omitted.

https://www.ruby-lang.org/en/news/2013/06/30/we-retire-1-8-7...

I can read too, announced here https://www.ruby-lang.org/en/news/2011/10/06/plans-for-1-8-7... . However I do think discontinuing security updates after 2 years announcement for a product that even they say is "more or less" used by everyone isn't the best decision.

> "more or less"

... on 6 Oct 2011.

They announced their plan. It was perfectly reasonable, and Ruby 1.9 was available way before that (2007) and at that time 1.9.3 was around the corner, so the clock was obviously ticking way before this announcement.

Ubuntu (and Debian) choses to stick on versions with releases, and maintain security as backported patches if need be, so the onus is now on them to secure their system.

It is a double edged sword to choose to rely on a system that favors sticking with older releases and rely on its own patches for bugfixing and security. One one hand you get tight integration between packages and platform stability, but on the other hand you get bitten back in such cases, and you can't blame upstream for that.

Re: Heap Overflow in Floating Point Parsing (CVE-2013-4164)

#8

Post by c3 »

c3 wrote: post #4

It seems to be a fairly simple patch for 1.8 series, too: https://bugs.ruby-lang.org/projects/ruby-193/repository/revisions/43776 just a few lines truncating input in util.c. Break your ruby here: JSON.parse("[1."+"1"*300000+"]")

update: I just tested this; if you're on 1.8.7, you can manually apply the patch I linked in the parent comment and recompile. There is nothing preventing a backport.

Re: Heap Overflow in Floating Point Parsing (CVE-2013-4164)

#9

Post by Sanddancer »

asdfaoeu wrote: post #5
yuhong wrote: post #3

Earlier quoted context omitted.

https://www.ruby-lang.org/en/news/2013/06/30/we-retire-1-8-7...

I can read too, announced here https://www.ruby-lang.org/en/news/2011/10/06/plans-for-1-8-7... . However I do think discontinuing security updates after 2 years announcement for a product that even they say is "more or less" used by everyone isn't the best decision.

Conversely, by not giving a shut off date, you get into the same situation Microsoft is in with Windows, where they have to support XP after over a decade. Supporting old software costs money, even if it is an open source project. You've had two years to work on a migration path, what were you doing in the interim?

Re: Heap Overflow in Floating Point Parsing (CVE-2013-4164)

#10

Post by rlpb »

lloeki wrote: post #7
asdfaoeu wrote: post #5

Earlier quoted context omitted.

I can read too, announced here https://www.ruby-lang.org/en/news/2011/10/06/plans-for-1-8-7... . However I do think discontinuing security updates after 2 years announcement for a product that even they say is "more or less" used by everyone isn't the best decision.

> "more or less" ... on 6 Oct 2011. They announced their plan. It was perfectly reasonable, and Ruby 1.9 was available way before that (2007) and at that time 1.9.3 was around the corner, so the clock was obviously ticking way before this announcement. Ubuntu (and Debian) choses to stick on versions with releases, and maintain security as backported patches if need be, so the onus is now on them to secure their syste…

> Ubuntu (and Debian) choses to stick on versions with releases

It's not as simple as just choosing. Every single package that depends on ruby 1.8 needs to move on before ruby 1.8 can itself be removed from the Debian or Ubuntu repositories. Either that, or the decision has to be made for laggard dependent packages to be removed. This takes time.

In Ubuntu, ruby1.8 is in main, which means that the Ubuntu Security Team will take care of the backported update.

Post reply on HN