Slashdot Mirror


Ruby On Rails SQL Injection Flaw Has Serious Real-Life Consequences

vikingpower writes "As a previous Slashdot story already reported, Ruby on Rails was recently reported to suffer from a major SQL injection flaw. This has prompted the Dutch government to take the one and only national site for citizens' digital identification offline (link in Dutch, Google translation to English). Here is the English-language placeholder page for the now-offline site. This means that 16 million Dutch citizens cannot authenticate themselves anymore with government instances, and that those same government instances can not communicate anything to those same citizens anymore." Fixes were released, so it looks like it's on their sysadmin team now.

117 comments

  1. LOL by Anonymous Coward · · Score: 1, Insightful

    Should have used ASP.NET

    1. Re:LOL by Anonymous Coward · · Score: 0

      Why use ASP.NET when ASP Classic still exists! Heck, fire it up on NT 4 Server and you're set!

    2. Re:LOL by Anonymous Coward · · Score: 0

      Then you'd have to wait until Feb 1st to fix the problem. Or is ASP.NET the new bug-free version?

    3. Re:LOL by AlphaBro · · Score: 2

      Laugh it up buddy, but LINQ to Entities largely eliminates SQL injection in ASP.NET web applications.

    4. Re:LOL by Anonymous Coward · · Score: 0

      Parameterized queries largely eliminate SQL injection in most web applications.

    5. Re:LOL by hackula · · Score: 1

      I hate ASP.Net with a fiery passion (VS the ram hog, leaky abstractions, encourages poor design, tries to be stateful, etc.), but Linq using lambdas has to be one of the most productive features of any language. You have to be careful, since it can easily turn perl-esque, but it dominates with throw away scripts with crazy powerful one liners. It is the one thing I have missed since switching to rails a couple years ago.

    6. Re:LOL by aztracker1 · · Score: 1

      Agreed, but when there is a critical flaw in the underlying structure, it won't help much... in this case you need the encryption key for the application to manipulate the cookies in play. If you have access to the encryption key, then it's pretty much game over anyways, as you already likely have access to everything.

      To the GP, in terms of Entity Framework, or any other ORM in modern web applications, you need to be diligent in what you transmit over the wire as any other system. I will usually create a new object to copy just what I need over in place... (View Models for MVC, and even in passing results for web services)... for my Node services backed by MongoDB, I have scrubbers that delete sensitive properties, and the _id (Mongo's identifier) field...

      The suggestion of the GP to work around the issues of one framework's security by using an even more closed framework is naive at best. I like the .NET stack, even more with ASP.Net MVC, LINQ etc. But it isn't the end-all, be-all by a long shot. Every language/platform I've used has me longing at times for something else that does X, Y or Z easier/better.

      --
      Michael J. Ryan - tracker1.info
    7. Re:LOL by AlphaBro · · Score: 1

      Parameterized queries used correctly mitigate SQL, but guess what? It's surprisingly easy to use them wrong, resulting in a false sense of security and vulnerable code.

    8. Re:LOL by AlphaBro · · Score: 1

      Amen brother. My passion for LINQ runs deep.

    9. Re:LOL by TechyImmigrant · · Score: 1

      Using a strongly typed language with a strongly typed database API, instead of that ugly hack called SQL will also mitigate SQL injections. Completely.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    10. Re:LOL by AlphaBro · · Score: 1

      Like Entity Framework, which I mentioned in my previous post? And be careful of absolutes when you're talking about security. Out of necessity, most ORMs offer ways to execute queries constructed via string concatenation and thus SQL injection can still occur.

    11. Re:LOL by AlphaBro · · Score: 1

      The suggestion of the GP to work around the issues of one framework's security by using an even more closed framework is naive at best. I like the .NET stack, even more with ASP.Net MVC, LINQ etc. But it isn't the end-all, be-all by a long shot. Every language/platform I've used has me longing at times for something else that does X, Y or Z easier/better.

      I overlooked this comment. Anyway, I did not suggest that EF was some end-all-be-all solution to security, because it is certainly not that. But if you're developing with ASP.NET, it's a safe bet that Microsoft's flagship ORM is going to play nicely with it, very nicely. LINQ-to-Entities with SQL offers a extremely pleasant experience, with the declarative style closely mirroring that of the SQL the queries are compiled into. This leads to cleaner, more concise code as opposed to other ORMs like Hibernate/NHibernate. And of course because you're writing strongly typed queries, the chances of SQL injection vulnerabilities are cut down dramatically. This should not be used as a crutch, and for reasons I've mentioned elsewhere in this thread SQL injection can still occur in just about all ORMs. There's no substitute for actually understanding software vulnerabilities, but don't be so quick to discount class-wide mitigations; they have proven to be effective in protecting end-users when developers make mistakes.

    12. Re:LOL by Alarash · · Score: 1

      What was the last ASP.NET vulnerability? Padding oracle _if_ you didn't know how to code. I think that's quite acceptable compared to a SQL Injection you can't do much about.

    13. Re:LOL by Anonymous Coward · · Score: 0

      I Couldn't agree more on the linq/lambdas/anonymous delegates.

      You say you hate ASP.NET because it encourages poor design & tries to be stateful. I think you specifically mean ASP.Net **WebForms** ASP.NET MVC is a totally different ball of wax.

      Also, depending on who you believe, ALL abstractions are leaky (http://www.joelonsoftware.com/articles/LeakyAbstractions.html).

    14. Re:LOL by TechyImmigrant · · Score: 1

      I don't think you got my point. I'm suggesting that SQL is contributing to the problem. Queries in is strings is not strongly typed. Function calls to BDB are. If you need an ORM to construct string queries, then you are trusting both yourself and the writers of the ORM framework writers to not screw up.

      It safest to trust the fewest people not to screw up and then not screw up yourself.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    15. Re:LOL by Jane+Q.+Public · · Score: 2

      "... compared to a SQL Injection you can't do much about."

      Quite the contrary; it is ridiculously easy to prevent this SQL injection attack. All you have to do is change the default "secret" key value, which should always be done in a Rails program.

      Every competent Rails programmer knows about the "secret" value, and that it should be changed from the default. They documentation clearly says so, and the file containing it says "Change this!". Failing to do so is akin to not changing the default password on your WiFi router... anybody can get in if they know how. (AND, in this case, if you happen to be using Authologic.)

      This is a "flaw" that normally affects only programs written by Ruby noobs. (Newby rubes...)

    16. Re:LOL by aztracker1 · · Score: 1

      My main point wasn't that EF + SQL + LINQ was bad... More that a platform change can be difficult to nearly impossible depending on the environment. A lot of my new development has been with EF and MVC or NodeJS and MongoDB. I like parts of each over the other, just depends on use cases.

      --
      Michael J. Ryan - tracker1.info
    17. Re:LOL by AlphaBro · · Score: 1

      I don't think you got my point, which is that strongly typed languages and APIs do not "mitigate SQL injections. Completely." You don't understand software security, do you?

    18. Re:LOL by TechyImmigrant · · Score: 1

      >You don't understand software security, do you
      Actually I do. It's my job. Well mostly hardware security, but they overlap.

      SQL injections are a problem of untrusted data being mistaken for trusted code. When data cannot be mistaken for code it makes it very difficult for traditional SQL injection to happen. SQL promotes the problems of data/code confusion because it is a text string that contains both and constructing and handling that string correctly has provided lots of scope for error.

      Keeping your data data and code code is great for mitigating SQL injection. It does nothing for a vast collection of other aspects of software security (E.G. xss, buffer overflow, side channels etc.), but for SQL injection, type safety in language and database API is just the ticket.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    19. Re:LOL by AlphaBro · · Score: 1

      Great, then you should have no problem understanding why I took issue with your claim. Very difficult <> impossible.

  2. Rockstars wanted by Anonymous Coward · · Score: 0, Funny

    That's all.

  3. Overraction by mortonda · · Score: 2, Insightful

    That's just silly, since the fix can be easily applied. It really nothing compared to all the wordpress exploits out the that never get patched.

    1. Re:Overraction by Anonymous Coward · · Score: 1

      They don't know if the vulnerability has been used to break into the site, so maybe they are restoring from backups, or verifying the integrity of the system?

    2. Re:Overraction by Anonymous Coward · · Score: 1

      Maybe they have a very old version and too much customization and they couldn't just apply a patch just like that. Assuming that everybody updates the OSS stuff religiously is naive. They generally have no clue that they have to do this on an ONGOING basis.

    3. Re:Overraction by Serious+Callers+Only · · Score: 5, Interesting

      This one is quite a serious flaw, and the data this website in question deals with is very important data (citizen IDs), so I'm not surprised they're taking it seriously. The service being down for a day or two is probably better than millions of ids getting hacked. Perhaps the fix breaks something on their website, and they have to fix that before they can take it back up again? It has produced issues like this I think:

      https://github.com/rails/rails/issues/8831

      Most sites (like Slashdot) really don't matter if they are hacked and could just stay up, but something dealing with identity like this deserves special attention, and I'm sure they have good reasons if they have taken the site down while they look at workarounds. Perhaps it'll mean they get more money devoted to securing the site after this has blown over - time spent testing the site and looking at security is probably more important than the specific technology used (almost every major framework has regular security problems like this), contrary to the righteous flaming and trolling for asp.net/perl/php/other tech which is bound to erupt in the wake of your post.

    4. Re:Overraction by slashdime · · Score: 5, Interesting

      Really? The Dutch government does a decent job at being serious on maintaining security of their citizens' identification data and your first thought is to criticize them for overreacting? You've obviously never worked with sensitive data. Any decent admin's reaction should have been the same if it included the possible leak of sensitive data. This is an entire country's data. You have no idea what you're talking about and should just shut your pie hole.

    5. Re:Overraction by mcvos · · Score: 3, Insightful

      A vulnerability in a blog is not quite the same thing as a vulnerability in a system used to submit tax returns.

    6. Re:Overraction by Floyd-ATC · · Score: 1

      So you don't think it's a good idea to err on the side of caution if you're in charge of a government authentication service for umpteen million citizens and perhaps make sure the fix works as intended before deploying it?

      --
      Time flies when you don't know what you're doing
    7. Re:Overraction by LordThyGod · · Score: 2

      Wrong (again!). What you meant to say was *WordPress plugins*, that are mostly abandoned open source projects. Your active support, participation, and superior intellect would surely be welcomed.

    8. Re:Overraction by Gr8Apes · · Score: 1

      The best answer to this would be to not use a system that is known to not be secure to begin with. That's a massive failure on the developer's part.

      --
      The cesspool just got a check and balance.
    9. Re:Overraction by jeffmeden · · Score: 1

      That's just silly, since the fix can be easily applied. It really nothing compared to all the wordpress exploits out the that never get patched.

      And a lot of governmental operations rely on Wordpress, do they?

    10. Re:Overraction by Anonymous Coward · · Score: 0

      I don't know why, but as I was reading your post... It was entirely in glen quagmire's voice. Interesting.

    11. Re:Overraction by Anonymous Coward · · Score: 0

      That's just silly, since the fix can be easily applied. It really nothing compared to all the wordpress exploits out the that never get patched.

      And a lot of governmental operations rely on Wordpress, do they?

      I can't tell because their site is down.

    12. Re:Overraction by benjymouse · · Score: 4, Insightful

      That's just silly, since the fix can be easily applied. It really nothing compared to all the wordpress exploits out the that never get patched.

      Really?

      This is a system that controls access to virtually all of the government public sites. It deals with extremely sensitive data and I guarantee you that no single administrator is allowed to download a patch and just apply it.

      It is not a hobbyist blogging site, it is a vital piece of a country infrastructure.

      Any change will have to be reviewed, tested and verified, with full sign off, logging, documentation and procedural oversight. The SOP when integrity cannot be guaranteed *should* be to shut down until reliable assessment can be made.

      --
      Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
    13. Re:Overraction by lysdexia · · Score: 1

      http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto I would have thought they'd gentrified by now.

    14. Re:Overraction by Serious+Callers+Only · · Score: 1

      Perhaps it'll mean they get more money devoted to securing the site after this has blown over - time spent testing the site and looking at security is probably more important than the specific technology used (almost every major framework has regular security problems like this), contrary to the righteous flaming and trolling for asp.net/perl/php/other tech which is bound to erupt in the wake of your post.

      The best answer to this would be to not use a system that is known to not be secure to begin with. That's a massive failure on the developer's part.

      QED

    15. Re:Overraction by Charliemopps · · Score: 2

      No, the best answer is not number every citizen and have those numbers be so important that it could do so much damage. No system could ever be secure enough for what the Dutch are doing. This doesn't even get into the privacy concerns and the havoc that could happen should the wrong people get into office.

    16. Re:Overraction by nedlohs · · Score: 1

      Silly???

      It's exactly what they should do. Rather than crossing their fingers and leaving it open and exploitable they've shut it down until they fix it. Sure that inconveniences the users and makes IT look bad, but it's the only correct choice.

    17. Re:Overraction by Andy+Prough · · Score: 0

      For me, it was in Cleveland's voice. I also don't know why. I think it was because of the term "You've obviously never worked with sensitive data". But, when I get to the last line, "You have no idea what you're talking about and should just shut your pie hole" - that's definitely a Peter Griffin line right there. In fact, this is possibly a conversation between Cleveland, Peter and Quagmire, instead of just one speaker, like this:

      Quagmire: "Really? The Dutch government does a decent job at being serious on maintaining security of their citizens' identification data and your first thought is to criticize them for overreacting?"

      Cleveland: "You've obviously never worked with sensitive data."

      Quagmire: "Any decent admin's reaction should have been the same if it included the possible leak of sensitive data. This is an entire country's data."

      Peter: "You have no idea what you're talking about and should just shut your pie hole."

    18. Re:Overraction by Anonymous Coward · · Score: 0

      I tried to read that blog, but whoever wrote it is definitely off their meds. Holy cow! Somebody should do a psych assessment on that guy before he hurts someone or himself.

    19. Re:Overraction by Anonymous Coward · · Score: 0

      It works better coming from Stewie than Peter. :-)

    20. Re:Overraction by LordThyGod · · Score: 0

      Why would anyone with a superior intellect develop for a piece of shit pile of security holes like Wordpress?

      Your turn, nigger.

      Why massa you don't have to develop for shit you don't like, you jus' have to tell us po' boys where the current security holes are. That's all. 2 minutes of your precious time, massa, is all we'uns ask. Your turn butthole.

    21. Re:Overraction by tarius8105 · · Score: 1

      Not to mention its so out dated I wonder how much of it is still relevant 5 years later.

    22. Re:Overraction by MakerDusk · · Score: 1

      This type of updates are always being released. If they updated regularly, it would not be such an issue. They didn't notice the security hole in the first place, so it's doubtful at best that they'd notice any more, let alone some created with a patch. This is most likely an example of set it up with a competent 3rd party, and then hire a clueless, but politically connected, head of IT. Yay for government jobs.

    23. Re:Overraction by mabhatter654 · · Score: 1

      Use an As400. Write your app in COBOL ... That ought to limit your hacker base to 40-70 year old males.

    24. Re:Overraction by Aighearach · · Score: 1

      No, the attack isn't as bad as advertised, you have to know the "secret" key used for the cookie data, even after this bug. This bug makes it so that if you use a known "secret" key for the session data, for example the default key from an open source package, then the session cookie can be used for a SQL injection exploit. All the major rails-based blog and ecommerce packages generate the key when you're installing. It is a standard step. And when you have a custom app, it is always generated and there is no default key.

      So the threat of attack is from people who have access to the production server account; generally, the people who already can just open a SQL shell.

      An important escalation to be aware of, but not a cause for alarm.

    25. Re:Overraction by Anonymous Coward · · Score: 0

      Nah, midrange is also for the younger ones...

    26. Re:Overraction by coma_bug · · Score: 1

      you have to know the "secret" key used for the cookie data

      That was last week. This time there are no conditions.

    27. Re:Overraction by Gr8Apes · · Score: 1

      Perhaps it'll mean they get more money devoted to securing the site after this has blown over - time spent testing the site and looking at security is probably more important than the specific technology used (almost every major framework has regular security problems like this), contrary to the righteous flaming and trolling for asp.net/perl/php/other tech which is bound to erupt in the wake of your post.

      The best answer to this would be to not use a system that is known to not be secure to begin with. That's a massive failure on the developer's part.

      QED

      Perhaps, except for the fact that building your security out of what essentially is the equivalent of a rail fence to keep out a flood is doomed to fail. (See what I did there?) There are tools that can work for your stated purpose, and there are tools that are wholly unsuited to the intended application. RoR falls into the latter camp. Oh, and then there's the fact that I didn't talk about about technology xyz, but the actual one selected, and limited my comments to facts regarding said technology. Most other technologies don't have this flaw as a core feature, you have to code it that way. So you might want to revisit your "QED".

      --
      The cesspool just got a check and balance.
    28. Re:Overraction by Gr8Apes · · Score: 1

      You have already been numbered - courtesy of your DNA.

      --
      The cesspool just got a check and balance.
    29. Re:Overraction by Big+Hairy+Ian · · Score: 1

      If they are doing it properly the performance testing alone would easily take at least a week. And another week for re doing security testing. Your idea of a release cycle is somewhat skewed.

      --

      Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.

    30. Re:Overraction by Serious+Callers+Only · · Score: 2

      Most other technologies don't have this flaw as a core feature, you have to code it that way. So you might want to revisit your "QED".

      Most other technologies do have exactly this kind of exploit (I think this is more serious than the article states, it's a remote execution flaw, not SQL injection as you seem to assume from reading the summary), and many have and will continue to suffer from SQL injection flaws as they find their safeguards weren't quite what they thought they were. Here's a hole in the Java from the day after (note that I don't think that makes Java immediately unsuitable for any use):

      http://developers.slashdot.org/story/13/01/10/1540202/java-zero-day-vulnerability-rolled-into-exploit-packs

      Security is a process, i.e. you have to keep continually on top of it and react quickly to disclosures. It's not something you can just assume because you chose 'secure' technology, or audit once and forget about, and it's not something which any particular technology has a monopoly on. It's quite possible to build secure sites with rails if you know what you're doing, do your own parameter checking on top of what rails provides, and keep on top of security updates. Perfect security probably isn't attainable with any language, but I'm sure you weren't implying that it was. Curious that you seem to think Rails is particularly insecure though, have you ever used it?

      Which tool in particular did you feel would work for this purpose? All the major languages or frameworks I can think of have had serious security problems in the past, none are a priori secure.

    31. Re:Overraction by mortonda · · Score: 1

      Yeah, I have to revise my statement, I didn't know about the second wave this week, and we are busy patching dozens of applications. All rails apps are vulnerable until updated. This is pretty darn serious in the rails community.

  4. Wrong title by Anonymous Coward · · Score: 0

    Te serious flaw is not SQL Injection but remote code execution (CVE-2013-0156)

  5. So? by Big+Hairy+Ian · · Score: 1, Funny

    16Mileon Dutch people cant authenticate? Smoke them if you've got them.

    --

    Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.

  6. Horrors! by Anonymous Coward · · Score: 0

    I too get mad when I can't authenticate myself with the government on a daily basis. I'm sure enraged citizens in Amsterdam and The Hague are burning copies of the pickaxe as we speak.

    1. Re:Horrors! by Anonymous Coward · · Score: 0

      Exactly my thoughts. What of value is being lost..?

  7. This is a different vulnerability by bimozx · · Score: 5, Informative

    This is a different security vulnerability that was brought to light a few days ago, which was given the full detail in this article. Finder method SQL Injection vulnerability Any Rails version that was build for the last 6 years is affected by this. This is a serious security flaw, it is sternly advised that you update your application immediately if your Rails version is in the bucket. You can refer to this discussion for more details.

  8. Ruby in Holland by fartrader · · Score: 0

    You can't even say :dyke anymore, it's women_in_comfortable_shoes()

  9. Real-Life Consequences?! by FreonTrip · · Score: 1

    That's even beginning to sound like... Full Life Consequences!

  10. Re:LOL Rubyists by Anonymous Coward · · Score: 1

    eh, ruby is a decent enough language. No comment on the users or RoR except to say a certain segment of idiots jumped from PHP to Ruby and are now (hopefully) jumping over to node.js.

  11. I've been saying it for years. by multicoregeneral · · Score: 5, Interesting

    And this, children, is why you actually need to know and understand SQL before you go off and start writing database applications, without depending on a "framework" to do it for you.

    --
    This signature intentionally left blank.
    1. Re:I've been saying it for years. by CastrTroy · · Score: 1

      You got marked as flamebait, but I have to agree. I find it amazing that this is even possible in something like RAILs which is supposed to abstract away all the SQL for you. You'd think that they would only be using parameterized queries, and not doing stupid string concatenation when forming SQL statements. There's a lot of frameworks out there that try to abstract away the SQL. I really don't understand the need for such things. SQL is a pretty simple language (at least the part that most frameworks abstract away). There's not reason to hide something like this. I personally find it takes longer to develop, and you end up with much more unreadable code when you use these frameworks.

      --

      Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
    2. Re:I've been saying it for years. by cout · · Score: 1

      I think your position is a reasonable one.

      However, it's not particularly relevant to the security hole. The bug has to do with deserialization of parameters rather than SQL specifically; the SQL injection exploit is but one possible exploit of the bug.

      Moreover it's not inconceivable (likely, in fact) that other bugs of the same class exist in projects other than rails. Avoiding Rails altogether doesn't protect you from this class of bug.

    3. Re:I've been saying it for years. by dam.capsule.org · · Score: 5, Informative
      --
      What sig ?
    4. Re:I've been saying it for years. by iluvcapra · · Score: 2, Informative

      You got marked as flamebait, but I have to agree. I find it amazing that this is even possible in something like RAILs which is supposed to abstract away all the SQL for you.

      Note, all parameters from the user's POST or GET are sanitized when passed to the finder methods, but developer-only parameters to the methods in question are exploited by the attacker sticking data into the server's Session object for the request, or by fooling the server into decoding a submitted parameter as a Hash of Symbol => Object pairs, instead of a String objects. This vector that's been described doesn't work unless the attacker has the HMAC that's signing the session cookie.

      The object method in question accepts either a string or a Hash of Symbol => Object pairs, and in the second case allows specifying arbitrary SQL clauses -- these are available for efficiency reasons and the documentation's pretty clear that these aren't sanitized, because they can't be. The problem for the attacker is somehow getting a user-created Hash, with Symbol keys, into the application, which is impossible through GET or POST parameters; the only way people have managed to do it is through forging a Session, which requires having the application's session shared secret.

      --
      Don't blame me, I voted for Baltar.
    5. Re:I've been saying it for years. by Anonymous Coward · · Score: 0

      I think you must have been using some really lousy frameworks if the SQL abstraction lead to unreadable code (I've only tried Django).

    6. Re:I've been saying it for years. by MillerHighLife21 · · Score: 1

      Totally agree with you. I was a long time Java, PHP developer and learned Rails to take over a project from a big firm in Atlanta. The level of BS these guys spew is insane. They chose Postgres as the database simply because its what Heroku says to do. I love Postgres, but if you are a major shop doing an application rewrite and not one person can articulate a reason for why you chose the backbone tech for the site...that is not good.

      They cared more about the code being "beautiful" than making sure it was functional, stable, efficient, and handled errors. To their credit they were big on writing unit tests and documenting things, but the level of inexperience that shows through from being framework dependent for so long is astounding.

      --
      "Don't teach a man to fish, feed yourself. He's a grown man. Fishing's not that hard." - Ron Swanson
    7. Re:I've been saying it for years. by Anonymous Coward · · Score: 0

      Or maybe we shouldn't be sending string literal text queries to a database server. This isn't the 1970s anymore and yet we keep doing these braindead things. SQL injection shouldn't even be possible.

    8. Re:I've been saying it for years. by shutdown+-p+now · · Score: 2

      There's nothing wrong with using a framework that does normal escaping (or, better yet, just uses parametrized queries consistently). The problem in this case is that Rails is too magical for its own good. So I would amend that to "don't use magical frameworks that claim to do everything without you doing nothing".

    9. Re:I've been saying it for years. by Anonymous Coward · · Score: 0

      What "guys"?

      And why does one need to explain the choice of PostgreSQL ?

    10. Re:I've been saying it for years. by colinrichardday · · Score: 1

      What would you use instead of Postgres?

    11. Re:I've been saying it for years. by Anonymous Coward · · Score: 0

      One of the many alternative databases out there, perhaps?

      It doesn't matter which. His point was that nobody knew why it was chosen. If I was asked about any of the technologies that are used in my place, I should at least be able to unearth an email where someone had put up the pros and cons of some options - and I would be embarrassed if I couldn't.

    12. Re:I've been saying it for years. by colinrichardday · · Score: 1

      Ok, I'd say that I wanted a cheap, reliable database, and I didn't want MySQL. The person being asked couldn't say that?

    13. Re:I've been saying it for years. by MillerHighLife21 · · Score: 1

      As stated, I love Postgres and there's many reasons to select it as a database. Nobody in charge of selecting it knew any of those reasons, which was shocking.

      It is a solid solution for this, but the level of inefficiency in the code this particular crew was putting out was appalling.

      Just a couple of "off the top of my head examples:

      There was a user dashboard system that showed users a list of buying, bought, sold, selling, and expired listings. Rather figure out what constituted any of these relationships existing and storing it somewhere each was figured out on the fly through a series of model relationships that checked against when they started, if any offers had been accepted, etc. So when listing things out they were retrieving all of this data (some long time users have as many as 18,000 listings), using ruby to go through and figure out whether it constituted sold/selling/buying/bought, which in and of itself was triggering hundreds of one-off queries behind the scenes to get the data from adjoining tables. All of that data, once aggregated into a RUNNING WEB PROCESS, was then sorted in an array in the web process. In many cases this crashed the server or put us so far over our RAM limits that we started using swap.

      We started running into duplicate listing URLs because they were depending on the uniqueness check in a ruby model, not even one they wrote btw one from a gem. At some point the gem was updated and redeployed with instructions to add a unique check to the field on the database. A) That should have been done in the first place because otherwise you're open to a race condition and B) since the gem update couldn't automatically do it and people don't generally read the change log when they pull updates for all of these gems we were left with duplicate url's all over the place.

      The stuff I just described happens when you have people writing code for a database that have no knowledge of what a database is doing, how it works, etc. It's just amateurish and those are only a couple of examples of the stuff I've been cleaning up in this code base since I took over the project.

      Regarding who they are, I'm not going to name them in a public forum. We don't work with them anymore. It's just like any other contract programming firm (I used to own one), the people at the top who started the company usually know what they're doing very well - that's why they started the company. Vouching for everybody else you hire to take on projects is a much harder task. 4 of their programmers worked on this project 2 of their top guys and 2 other guys. The top guys did a great job. I've only found a couple of minor detail issues with the work from them. The other 2 guys work was so shoddy it nearly killed the company I work for.

      The root of the problem is this: The company is an agile shop and has a development process that works very smoothly for from-scratch projects where you can correct scaling issues as the site traffic grows. It's an utter disaster of a process for rebuilding a system that is already a high traffic site and is effectively "at scale" when launched.

      --
      "Don't teach a man to fish, feed yourself. He's a grown man. Fishing's not that hard." - Ron Swanson
    14. Re:I've been saying it for years. by Anonymous Coward · · Score: 0

      The guys who need an insanely complex, dynamic, brittle crapola to write SQL for them. Because they haven't grasped relational theory.

    15. Re:I've been saying it for years. by Anonymous Coward · · Score: 0

      So if the leaders could not vet and/or train their underlings, they are even bigger muppets. Can we call it "Muppets On Rails" ?

      As I said, real work is done with Cobol.

    16. Re:I've been saying it for years. by coma_bug · · Score: 1

      That was last week. This time it's ARBITRARY CODE EXECUTION without conditions. Please try to keep up.

    17. Re:I've been saying it for years. by coma_bug · · Score: 3, Insightful

      This vector that's been described doesn't work unless the attacker has the HMAC that's signing the session cookie.

      That was last week. This time attackers can bypass authentication systems, inject arbitrary SQL, inject and execute arbitrary code, or perform a DoS attack. Please try to keep up.

    18. Re:I've been saying it for years. by TechyImmigrant · · Score: 1

      And this, children, is why you actually need to know and understand SQL before you go off and start writing database applications, without depending on a "framework" to do it for you.

      To know and understand SQL is to know and understand that it is a steaming pile and other interfaces should be used.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    19. Re:I've been saying it for years. by iluvcapra · · Score: 1

      But this is just as hard to invoke, because it requires the application to take a string from an untrusted source, parse it as YAML or XML, and then use the resulting Hash as an argument -- this would only happen if you were taking some sort of web service request or submitted file, parsing it without validation, and then passing it verbatim to the ActiveRecord finder methods.

      Parsing untrusted information and then passing it to the API without any validation is a fail. This is a nominal exploit, but you never pass a parsed raw YAML or XML fragment from a tainted source to the .find_by_* methods - they wouldn't accept decoded XML or YAML in the non-exploitable case, unless you've gone out of your way and are passing shrink-wrapped API call arguments to the client for them to edit.

      --
      Don't blame me, I voted for Baltar.
    20. Re:I've been saying it for years. by iluvcapra · · Score: 1

      I don't understand, a new Rails application without any controllers doesn't parse user-provided YAML...

      --
      Don't blame me, I voted for Baltar.
  12. WHAT THE FUCK IS WRONG WITH THE MODERN WORLD? by Anonymous Coward · · Score: 0

    Why is stuff like this even being made available using some generic framework built by a bunch of students?

    How the hell can something be designed so badly that it is possible to have a database injection vulnerability? What kind of broken isolation of layers allows that to happen?

    This is what happens when you privatise government.

    1. Re:WHAT THE FUCK IS WRONG WITH THE MODERN WORLD? by seebs · · Score: 5, Insightful

      You know, it's pretty obvious that you're trolling, but there's a real question here:

      Why would we use frameworks, given that they have security bugs coming up all the time?

      Answer: Because code people write themselves isn't any less buggy, and with a framework, at least you have other people looking for bugs too.

      --
      My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
    2. Re:WHAT THE FUCK IS WRONG WITH THE MODERN WORLD? by greg_barton · · Score: 1

      seeeeeeeeeebs! Wish I had a mod point for you. :)

    3. Re:WHAT THE FUCK IS WRONG WITH THE MODERN WORLD? by rubycodez · · Score: 1

      oh, because expensive proprietary frameworks (eg websphere or weblogic) or other open source ones (zend) never have such vulnerabilities?

      you're ignorant

  13. Ruby on Fails by thetoadwarrior · · Score: 1

    Rails is a vulnerability. Using it is like using PHP so don't count on security.

  14. Not obvious what is actually at issue. by seebs · · Score: 1

    Down for upgrades? Down for an evaluation of whether upgrades are needed? Down for code fixes? Down because they need to evaluate what happened after confirming attack happened?

    The actual vulnerability was not automatically present; it's easy to use Rails and not have this vulnerability affect you, because while the vulnerability is nominally in the code base, there's no paths to trigger it without specific code -- so either you'd have to use a specific third-party library, or write your own code which does the same things. So it might well be that the site is not actually vulnerable -- and they're just being cautious.

    Which I don't think is overreacting.

    --
    My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
    1. Re:Not obvious what is actually at issue. by MakerDusk · · Score: 1

      so either you'd have to use a specific third-party library, or write your own code which does the same things. So it might well be that the site is not actually vulnerable

      This is /. writing code is no discouragement to anyone here. If all you had to do to steal all social security information for an entire country was 'write your own code', there will be takers.

    2. Re:Not obvious what is actually at issue. by Anonymous Coward · · Score: 0

      This is /. writing code is no discouragement to anyone here. If all you had to do to steal all social security information for an entire country was 'write your own code', there will be takers.

      He's talking about the site developer, not the attacker, moron.

  15. Toy by QuietLagoon · · Score: 1, Insightful

    Why is a toy programming environment like Ruby on Rails used for such a critical infrastructure?

    1. Re:Toy by MakerDusk · · Score: 1

      Generally, because it's easy to write and, if properly implemented, is extreamly effecient for extreamly large, decentralized nosql databases.

  16. "Fixes were released, so it looks like it's on by obarthelemy · · Score: 1

    their sysadmin team now."

    I laughed

    1- Maybe implementing, validating, testing... the fix does take a bit of time ?

    2- This sounds so much like a teenager "But Daddy, I know last time I went out I got back past curfew drunk and smelling of cigarettes... but that was LAST TIME, I'm trustworthy now... what's the hold-up ?"

    --
    The Cloud - because you don't care if your apps and data are up in the air.
    1. Re:"Fixes were released, so it looks like it's on by Anonymous Coward · · Score: 0

      I fully expect this "dynamic" thing to dynamically open up 25 more serious flaws in the next three years.

  17. Exaggerated by Fuzzums · · Score: 1

    This means that 16 million Dutch citizens cannot authenticate themselves anymore with government instances ON LINE, and that those same government instances can not DIGITALLY communicate anything to those same citizens anymore.

    So instead, you make a phone call?

    --
    Privacy is terrorism.
    1. Re:Exaggerated by Anonymous Coward · · Score: 1

      This system is for example used for authenticating our tax-submission. It's quite vital for a lot of communication between goverment and civilians, since there are no (easy) other ways to perform such by law enforced civil tasks.

      ps: a month a ago there were problems with the phone and it wasnt even possible to dail 911 (112)

  18. Let's not overreact by Aethedor · · Score: 1

    It is a computer system. Like *every* computer system, it has flaws and one of those flaws can be a security flaw. The real issue is how the flaw is being handled. One can deny it, one can secretly fix it or one can take responsiblity, inform its users and fix the issue. The last is the only correct way and it is the way the DigiD issue was handled. So, no 'real-life consequences', just another side effect of the digital age. It will soon be solved and live goes on. Nothing to see, move along.

    --
    It doesn't have to be like this. All we need to do is make sure we keep talking.
  19. Laughing My Ass Off by Anonymous Coward · · Score: 0

    "vital piece of a country infrastructure."

    And they use a framework which allows for SQL injections, it now transpires ? A "dynamic" framework hacked together by hobo-programmers ? Yeah, this was some kind of scheme by politicians to help their web-brogrammer friends into a nicely paying PORKBARREL CONTRACT.

    If these politicos had been serious, they would have used the L4 kernel and a tried and tested Ada compiler for that purpose. They would have hired the people who secure Airbuses against crash-by-cyber-attack. But these are Software Engineers, not long-haired hippe Web-Brogrammers.

    1. Re:Laughing My Ass Off by Anonymous Coward · · Score: 0

      http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto

  20. And That Means It Is Ruby On Muppets by Anonymous Coward · · Score: 0

    The suuuper-dynamic web-brogrammer hippies apparently discover in the year 2013 what the consequences of "non-existent random initialization of cryptographic keys and generators" are. I guess they are all social science majors and have never ever thought about the concept of randomness. After all, "society is a system with well-defined rules". The world is deterministic and randomness does not exist. I am sure their socialworker-in-chief hashes "decides" on their random numbers.

    1. Re:And That Means It Is Ruby On Muppets by Anonymous Coward · · Score: 0

      Hint to brogrammers: /dev/random

    2. Re:And That Means It Is Ruby On Muppets by TechyImmigrant · · Score: 1

      Hint to brogrammers: /dev/random

      Which will either block or give you data with no entropy unless you really know what you're doing.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
  21. They Are Clueless by Anonymous Coward · · Score: 0

    It actually is a cryptographic issue, but in their "dynamic web shallowness" there exist only "SQL Injections". These are all muppets without a computer science education. That is the core of the problem. Stay away from them at all cost.

    Here's a nickel and a proper programming language, boy: http://lazarus.freepascal.org/

  22. Real Software Engineers by Anonymous Coward · · Score: 0

    ..code in Cobol and S/360 assembly. That Ruby thing is for the hobos to put a thin layer of crap in front of the well-paid pros and their mainframes.

    1. Re:Real Software Engineers by MillerHighLife21 · · Score: 1

      There's nothing wrong with Ruby. I love Ruby. For production deployments I'm also finding that jRuby fixes the bulk of Ruby's issues under load.

      The problem is the dependency on Active Record without the slightest understanding of how the database behind it works, focussing on writing all of your code in ruby and not take the slightest advantage in letting your database do what it's specifically BUILT to do. If you wanted to say, get 20,000 of 500,000 records from a database in a certain order would you pull all of them into ruby just so you could use an array sort function on them or would you sort and filter them at the database level? You'd filter them at the database level. The people I'm referring to, would go the other route.

      The search results page of this site used to run 2,000 queries to show 100 results. That's not hobos, that's morons.

      --
      "Don't teach a man to fish, feed yourself. He's a grown man. Fishing's not that hard." - Ron Swanson
  23. Brogrammers.... by Anonymous Coward · · Score: 0

    Because the brogrammers who built the propaganda website for a politico now need a proper pork project. Meanwhile the real work is done on Cobol by adults in the national retirement insurance agency.

  24. NOT by Anonymous Coward · · Score: 0

    I do think this incident, very much like the DigiNotar issue raised the question "can computers actually be used for anything truly important ??"

    As it stands, the answer is a resounding "NO". We can NOT sign legally binding contracts using computers. We cannot rely on digital authentication to conduct government business. It seems we have to show up at a local government office and use some meatspace method of authenticating our important business. It seems that personally knowing people is actually a requirement for proper security.

    The whole notion of "we are modern and use computers for everything" has been royally fucked through all bodily openings.

    Wait until MOSSAD assassinates someone with stolen/counterfeittted Dutch ID cards/passports (based on data lifted from that super-insecure "dynamic" site), before you say "no but".