All Ruby On Rails Versions Suffer SQL Injection Flaw

← Back to Stories (view on slashdot.org)

All Ruby On Rails Versions Suffer SQL Injection Flaw

Posted by timothy on Thursday January 3, 2013 @04:35AM from the this-tunnel-under-construction dept.

Trailrunner7 writes with the news as posted at Threatpost (based on this advisory) that "All of the current versions of the Ruby on Rails Web framework have a SQL injection vulnerability that could allow an attacker to inject code into Web applications. The vulnerability is a serious one given the widespread use of the popular framework for developing Web apps, and the maintainers of Ruby on Rails have released new versions that fix the flaw, versions 3.2.10, 3.1.9 and 3.0.18. The advisory recommends that users running affected versions, which is essentially anyone using Ruby on Rails, upgrade immediately to one of the fixed versions, 3.2.10, 3.1.9 or 3.0.18. The vulnerability lies specifically in the Ruby on Rails framework, and its presence doesn't mean that all of the apps developed on vulnerable versions are susceptible to the bug."

81 comments

Min score:

Reason:

Sort:

Ruby on Wails! by Anonymous Coward · 2013-01-03 04:44 · Score: 0

Upgrade to visual basic you losers!
1. Re:Ruby on Wails! by Runaway1956 · 2013-01-03 06:20 · Score: 1
  
  http://www.youtube.com/watch?v=TprfUdSAHgM
  
  --
  "Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
bug found, bug fixed, bug deal by Anonymous Coward · 2013-01-03 04:44 · Score: 0

Since when is a patch news?
1. Re:bug found, bug fixed, bug deal by Desler · 2013-01-03 04:48 · Score: 5, Insightful
  
  When it's a major security flaw? SQL injection is one of the most common attack vectors to compromise websites and servers. It seems perfectly valid that this security advisory is spread far and wide.
2. Re:bug found, bug fixed, bug deal by Anonymous Coward · 2013-01-03 05:15 · Score: 0
  
  Since when is a patch news?
  Wow, you must be new here. News like bugs and patches (for stuff like MySQL, Perl, PHP, the Linux kernel, etc) were more or less what Slashdot was founded on. You know, news for nerds?
3. Re:bug found, bug fixed, bug deal by Serious+Callers+Only · 2013-01-03 05:28 · Score: 5, Informative
  
  When it's a major security flaw?
  According to the article, this is not in fact a major security flaw, unless you have made your secret session key (HMAC) for the app public, and are using old style finder methods like find_by_id(2) etc. For a start the attacker has to know your HMAC - this is randomly generated when creating a rails app, and is not supposed to be publicly disclosed, though if your app is open source and you forgot to change it and left it in a public repo, it is possible someone could find it. The vast majority of rails apps this is not going to apply to, and there are obvious reasons you shouldn't make your session signing key public anyway.
  So it looks like this is a bug which the majority of rails users won't have to worry about, but it's good that they fixed it.
4. Re:bug found, bug fixed, bug deal by Desler · 2013-01-03 05:34 · Score: 1
  
  The majority may not but it's not unheard of that developers slip up and make their secret keys public.
5. Re:bug found, bug fixed, bug deal by Synerg1y · 2013-01-03 05:45 · Score: 1
  
  I'm confused though, why allow this possibility in the first place? There's a ton of locations I can think of off the top of my head to store an app key that's better than the root of the application.
6. Re:bug found, bug fixed, bug deal by someones · 2013-01-03 05:46 · Score: 1
  
  we are talking about RUBY on RAILS here...
  everything diffrent from: its finally dead is news
7. Re:bug found, bug fixed, bug deal by Anonymous Coward · 2013-01-03 05:50 · Score: 0
  
  Every Rubybbook recommends using things like *.find_by_id, last I checked. What makes you say this is the older style method? It seems to be fully supported and recommended. Serious question.
8. Re:bug found, bug fixed, bug deal by Serious+Callers+Only · 2013-01-03 06:09 · Score: 1
  
  The newer style without dynamic finders would just be Model.find(2), or Model.where(:id => 2). The books you are looking at are a little out of date perhaps.
9. Re:bug found, bug fixed, bug deal by Serious+Callers+Only · 2013-01-03 06:17 · Score: 2
  
  If you publish the key used to sign sessions, people could fake session cookies and log in as someone else for example so this vulnerability would be the least of your problems. It's a problem all by itself, and is not something that is possible to do without publishing your entire app source on GitHub for example and forgetting to hide the passwords/keys which should be kept private (e.g db passwords, hmac). You can't publish it by mistake by misconfiguring your web server for example, it would have to be a deliberate choice to publish the entire app source on another channel including secrets.
  So for the majority of sites it seems this vuln (and others requiring the secret key) is a non-issue.
10. Re:bug found, bug fixed, bug deal by Anonymous Coward · 2013-01-03 06:28 · Score: 0
  
  But if you don't submit your keys/etc, when GPL can't work! Think of all code being "stolen".
  
  GPL likes to cherry pick. /sarc
11. Re:bug found, bug fixed, bug deal by cjc25 · 2013-01-03 06:51 · Score: 1
  
  Model.where(some_field: 5) is not the same as Model.find_by_some_field(5). The #where method returns a lazily evaluated database request which functions more or less like an array. #find_by_... returns either the "first"* model to match or nil if no models match and is much more useful for one-liners
  * IIRC no ordering is guaranteed unless you have an #order portion in your model default scope
You ALL have to upgrade! by Anonymous Coward · 2013-01-03 04:44 · Score: 0

You ALL have downtime! Hahahahaha!
1. Re:You ALL have to upgrade! by K.+S.+Kyosuke · 2013-01-03 05:34 · Score: 1
  
  Just like Smalltalk, a Ruby process can modify its code while it's running. No need for downtime, unless they are doing something wrong.
  
  --
  Ezekiel 23:20
this flaw only applies if you use authlogic by Anonymous Coward · 2013-01-03 04:44 · Score: 0

this flaw only applies if you use authlogic
1. Re:this flaw only applies if you use authlogic by Desler · 2013-01-03 04:54 · Score: 2, Informative
  
  No, the flaw applies if you are not using authlogic.
  
  This is why most Rails apps that are running Authlogic are not exploitable
2. Re:this flaw only applies if you use authlogic by dririan · 2013-01-03 05:28 · Score: 4, Informative
  
  A known exploitable scenario is when all of the following applies:
  1. You're using Authlogic (a third party but popular authentication library).
  2. You must know the session secret token.
  http://blog.phusion.nl/2013/01/03/rails-sql-injection-vulnerability-hold-your-horses-here-are-the-facts/
  
  Seems like you are mistaken. I believe they were saying that merely using Authlogic doesn't automatically make you vulnerable, but you need to be using it to be vulnerable.
3. Re:this flaw only applies if you use authlogic by Anonymous Coward · 2013-01-03 05:32 · Score: 0
  
  No, what you said applies only if you are not using any logic.
  Seriously, this injection is only triggered if you use Authlogic. No need to confuse folks. Proof.
4. Re:this flaw only applies if you use authlogic by IAmGarethAdams · 2013-01-03 11:41 · Score: 1
  
  Seems like you are mistaken. The very next sentence after the block you quoted says:
  
  There are other exploitable scenarios, but it really depends on what your app is doing. Since it is impossible to prove that something isn’t insecure, you should take the vulnerability seriously and upgrade anyway even if you think you aren’t affected.
5. Re:this flaw only applies if you use authlogic by dririan · 2013-01-03 12:02 · Score: 1
  
  Do you feel witty copying my first sentence? In any case, you are correct, I neglected to say "but you need to be using it as your authentication framework". There aren't any others that are noted to be vulnerable that I can find. If you're using your own custom authenticator, there's no reason to have a marshaled hash in your cookie. If someone can provide an example of a custom authentication setup that uses marshaled hashes, please do cite it.
  
  Furthermore, I don't know of any Rails web sites that let you submit a marshaled hash and then perform a query with it. So unless you can find one (or a custom authenticator that uses them), it's only Authlogic.
Rails 2.x? by Bovius · 2013-01-03 04:45 · Score: 1

I suppose their advice for those running legacy deployments of Rails 2.x apps is to upgrade to 3.x. Rad.
1. Re:Rails 2.x? by Anonymous Coward · 2013-01-03 05:07 · Score: 0
  
  FTFA
  
  * 3-2-dynamic_finder_injection.patch - Patch for 3.2 series
  * 3-1-dynamic_finder_injection.patch - Patch for 3.1 series
  * 3-0-dynamic_finder_injection.patch - Patch for 3.0 series
  * 2-3-dynamic_finder_injection.patch - Patch for 2.3 series
select by Anonymous Coward · 2013-01-03 04:46 · Score: 0

'First post'; drop database
1. Re:select by webnut77 · 2013-01-03 08:54 · Score: 1
  
  Is that you, little Bobby?
Ruby Injection by schneidafunk · 2013-01-03 04:49 · Score: 1

Correct me if I'm wrong, but in Ruby on RAILS, doesn't the database calls execute through a ruby function? So you are not injecting SQL, but some ruby that then executes SQL.

--
Some people die at 25 and aren't buried until 75. -Benjamin Franklin
1. Re:Ruby Injection by Anonymous Coward · 2013-01-03 05:19 · Score: 1
  
  This is an arbitrary SQL injection vulnerability. According to the advisory, it is in the very core of the Active Record. Anyone who has ever programmed for RoR has definitely used the following:
  
  Post.find_by_id(params[:id])
  
  This is the standard way of finding a DB record by ID, and advised like this in all RoR books. It is one of the most fundamental calls in the whole framework.
  Now, according to the advisory, the automatic type conversion (again, one of the core features of Ruby) can be exploited to produce an SQL injection from this. The issue can be mitigated by using explicit type conversion:
  
  Post.find_by_id(params[:id].to_s)
2. Re:Ruby Injection by Serious+Callers+Only · 2013-01-03 06:25 · Score: 1
  
  Actually that's not true, since 3.0 at least the default style (from scaffolds for example) has been Post.find(params[:id]), many people don't use dynamic finders at all, as you can use where(...) and scopes instead.
  Also, according to the advisory, the HMAC is required, that's really very unusual and important.
3. Re:Ruby Injection by johnw · 2013-01-03 08:32 · Score: 3, Informative
  
  This is an arbitrary SQL injection vulnerability. According to the advisory, it is in the very core of the Active Record. Anyone who has ever programmed for RoR has definitely used the following:
  Post.find_by_id(params[:id])
  This is the standard way of finding a DB record by ID, and advised like this in all RoR books. It is one of the most fundamental calls in the whole framework.
  Not true - the more natural (and non-vulnerable) way to write this is:
  Post.find(params[:id])
  and that's the way normally recommended in books on the subject.
4. Re:Ruby Injection by Anonymous Coward · 2013-01-03 09:18 · Score: 0
  
  Not true - the more natural (and non-vulnerable) way to write this is:
  Post.find(params[:id])
  Doesn't seem to matter. If the attacker is able to control the type of params[:id] they can still execute arbitrary SQL, because Post.find also has :select named argument just like find_by_X.
  Though there might be some reason why it wouldn't work, that I can't think of.
5. Re:Ruby Injection by Anonymous Coward · 2013-01-03 21:14 · Score: 0
  
  Not true - the more natural (and non-vulnerable) way to write this is:
  Post.find(params[:id])
  and that's the way normally recommended in books on the subject.
  Yes, for the id column. For any other column, it's Post.find_by_somecolumn(params[:someval])
Pthhhhttpppt by Anonymous Coward · 2013-01-03 04:50 · Score: 5, Informative

Had me freaked out for a second, but then I RTFA (on accident I swear). Nothing to see here, please move along. If they have your HMAC key you are doing it wrong.

"So to inject arbitrary SQL, you need to tamper with the cookie, which requires the HMAC key. The HMAC key is the so-called session secret. As the name implies, it is supposed to be secret. Rails generates a random 512-bit secret upon project creation. This is why most Rails apps that are running Authlogic are not exploitable: the attacker does not know the secret. Open source Rails apps however can form a problem. Many of them come with a default session secret, but the user never customizes them, so all those instances end up using the same HMAC key, making them very easily exploitable. Of course, in this case the operator have to worry about more than just SQL injection. If the HMAC key is known then anybody can send fake credentials to the app."
1. Re:Pthhhhttpppt by larry+bagina · 2013-01-03 05:13 · Score: 5, Insightful
  
  Joe Public shouldn't have your HMAC key, but Joe Disgruntled Former Employee/Consultant might. And he might also be disgruntled.
  
  --
  Do you even lift?
  These aren't the 'roids you're looking for.
2. Re:Pthhhhttpppt by LordLimecat · 2013-01-03 05:49 · Score: 1
  
  Forgive me if this is a silly question, but isnt "sending fake credentials to the front-end app" significantly less worrisome than "can send arbitrary SQL commands to the backend DB"?
3. Re:Pthhhhttpppt by Serious+Callers+Only · 2013-01-03 06:27 · Score: 1
  
  Not really no, as they could impersonate an admin account and use that to execute whatever commands they wish.
4. Re:Pthhhhttpppt by DragonWriter · 2013-01-03 06:28 · Score: 1
  
  Forgive me if this is a silly question, but isnt "sending fake credentials to the front-end app" significantly less worrisome than "can send arbitrary SQL commands to the backend DB"?
  It shouldn't really be, because if the backend DB is secured properly, "can send fake credentials to the front-end app" and "can explot the front-end app to send arbitrary SQL to the back-end DB" should be exactly equivalent, since the backend DB should only allow the front-end app's account to do things that the front-end app is allowed to do, so that sending arbitrary SQL through the app shouldn't allow you to cause any havoc that impersonating the most-privileged-user to the app wouldn't also allow you to do. Though, that being said, I suspect there are a lot of Rails apps out there where the backend DB isn't secured properly.
5. Re:Pthhhhttpppt by TheNinjaroach · 2013-01-03 07:01 · Score: 1
  
  That's akin to not changing system passwords after someone leaves the department.
  
  --
  I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
6. Re:Pthhhhttpppt by IAmGarethAdams · 2013-01-03 11:45 · Score: 2
  
  Right, but the HMAC session key is used to encrypt user sessions. Change the key, and all the old sessions become invalid. Your suggestion is akin to saying, after someone stops working at your company, every user of the company's website should get logged out.
Hold your horses by bimozx · 2013-01-03 04:51 · Score: 5, Informative
rails sql injection vulnerability hold your horses here are the facts

Too briefly re-iterate certain main important points in the article.
- - It does not mean all unupgraded Rails apps are suddenly widely vulnerable.
- - It does not mean Rails doesnâ(TM)t escape SQL inputs.
- - It does not mean Rails doesnâ(TM)t provide parameterized SQL APIs.
- - It does not mean Rails encourages code that are inherently prone to SQL injection. The code should be safe but due to a subtlety was not. This has been fixed.
More information by FooBarWidget · 2013-01-03 04:54 · Score: 4, Informative

This article explains what the vulnerability is, how it is triggered, how severe it is and what the facts are.
1. Re:More information by Ksevio · 2013-01-03 05:13 · Score: 1
  
  So it looks like it centers around an attacker having your private key - which if they have would cause other major issues anyways. Not exactly newsworthy.
2. Re:More information by Anonymous Coward · 2013-01-03 05:21 · Score: 1
  
  Except that folks who don't know better are checking these files into their public repository and handing the attacker the private key.
3. Re:More information by Anonymous Coward · 2013-01-03 05:38 · Score: 0
  
  There seems to be a tendency in dynamic languages like Ruby to guess the binding between positional arguments and parameters dynamically, based on types. The phusion.nl article describes such a case. When given a symbol-keyed hash as its only argument, ActiveRecord's find_* methods treat it as a set of options, instead of the thing to find. Something as basic as passing the correct arguments to the correct parameters is left up to ad-hoc guessing at run-time, seemingly just so a programmer can lazily throw objects at the method and hope it correctly guesses what to do with them. I appreciate the do-what-you-mean philosophy behind it, but I think it might be taking it to an insecure and difficult to reason about extreme.
4. Re:More information by FooBarWidget · 2013-01-03 05:49 · Score: 1
  
  That is one, and probably the most common, attack vector. There are other ways to introduce attack vectors as well, documented under the "Other exploitable scenarios" section. Even if you believe you are not vulnerable you should upgrade.
But..., but... by Jawnn · 2013-01-03 05:13 · Score: 0

How can this be? Ruby on Rails is all magical goodness, right?
El Oh El by Anonymous Coward · 2013-01-03 05:16 · Score: 0

You Dagw! I heard you like frameworks, so I put vulnerabilities in your framework made of frameworks to replace frameworks.
Re:this is why Ruby sucks by Anonymous Coward · 2013-01-03 05:20 · Score: 0

Why this got modded up? Ruby isn't a framework, so putting it in the same category as RoR and "all other frameworks" is so obviously an ignorance that it makes me uninterested in any opinion in this statement.
The perils of clever coding in dynamic languages by Anonymous Coward · 2013-01-03 05:26 · Score: 1

This exploit arises directly from clever code that hooks function names that don't even exist in the text of the codebase. So instead of find([:id]), you type find_by_id(). If I understand it correctly, the method-not-found exception handler pulls out the symbol from the function name itself and calls find(). This is the kind of crap that Ruby developers think is cool and useful.
In Ruby, you are never coding by contract - you are coding by duck tape. It's an awesome language for throwing together a prototype - it's often my go-to language for such things. But putting Ruby code into production is asking for exploits like this to find your clever code.
Security and defaults don't mix by Anonymous Coward · 2013-01-03 05:29 · Score: 0

Nor does dynamic typing -
"oh, you probably want a string, but it looked like a set of key,value pairs so I converted it for you! Silently of course. No need to thank me".
Later:
"I don't need no static typing to tell me what type this object is dammit! Fred told me that function returns a string and he never writes buggy code - he even wrote a bunch of unit tests and they all pass - of course its a fucking string. I'll just pass this "string" object to this runtime generated function which does different things depending on the type of parameter I pass - hey its built in to Rails, so that must be good design"
Re:this is why Ruby sucks by Anonymous Coward · 2013-01-03 05:32 · Score: 0

Do not feed the troll. TIA
Re:They must be directly executing it then by Anonymous Coward · 2013-01-03 05:42 · Score: 0

its obviously not a problem if you just used host files right !
Re:DHH posted recently... by Anonymous Coward · 2013-01-03 05:48 · Score: 0

With all the duck taping, monkey-poo patching, and meta-meta-meta brogramming, I am not surprised with all these active-security-holes.
You're obviously an off topic troll by Anonymous Coward · 2013-01-03 06:01 · Score: 0

Who has no clue on making parameterized queries you pass to stored procedures DB server side then via a bound variable, to help stall SQL Injection based attacks...
* Grow up troll, & get on topic... & quit 'stalking' me - thank you!
APK
P.S.=> This constant 'harassment' & stalking of myself regarding host files though?
Well, tell you what - you disprove the things I list that a custom hosts file can do for end users of them on a myriad of levels to good effect for them:
http://start64.com/index.php?option=com_content&view=article&id=5851:apk-hosts-file-engine-64bit-version&catid=26:64bit-security-software&Itemid=74
As they are listed right there, enumerated?
Then, you'll have made a SOLID point - for once!
However, I absolutely KNOW you cannot, & it's also quite obvious I've trashed you before on this very challenge as well!
(Thus, your truly cowardly anonymous trolling posts - IF you did so as your registered 'luser' account here, you KNOW I'd "toss it back in your face" as to the times I've burned YOU, on THIS VERY CHALLENGE, before... you know it, I KNOW IT, & anyone else reading would too, based on your reprehensible behavior now & other times you've done this stalking of myself this way on this website forums)...
... apk
1. Re:You're obviously an off topic troll by interval1066 · 2013-01-03 06:28 · Score: 1
  
  ...wtf are you mumbling about???
  
  --
  Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
2. Re:You're obviously an off topic troll by Anonymous Coward · 2013-01-03 06:43 · Score: 0
  
  The hosts file edits you do are considered a "hacked up" non-solution. The wrong way to do things. It's not what the hosts file is intended for. We understand that it achieves the same end result. But is not the proper solution.
  Wiping your LCD off with toilet paper achieves the same end result. But it is not the right tool for the job when there is proper LCD cleaning solutions.
  Wiping your ass with LCD cleaning wipes achieves the same end result. But it is not the right tool for the job when there is toilet paper.
  You should, instead, be running your own DNS server. You should be offloading the blacklist from the client to the server. This provides a centralized way to manage the blacklist. I run my own DNS server at home and connect to it via VPN when I'm traveling.
3. Re:You're obviously an off topic troll by Anonymous Coward · 2013-01-03 08:48 · Score: 0
  
  It's ... apk. The /. equivalent to someone who pushes people in front of subway trains.
4. Re:You're obviously an off topic troll by Anonymous Coward · 2013-01-03 09:02 · Score: 0
  
  * Grow up troll, & get on topic... & quit 'stalking' me - thank you!
  You know, APK, Anonymous Coward is a shared id for non-authenticated posters, right? It's not allways the same guy.
How are all versions effected? by GarryFre · 2013-01-03 06:02 · Score: 1

If they have just released a fixed version than how can it be said that ALL versions are vulnerable? Really this sensationalism over fact gets irritating.

--
www.Migrainesoft.com - Computer giving you a headache? We can fix that!
1. Re:How are all versions effected? by DragonWriter · 2013-01-03 06:31 · Score: 1
  
  If they have just released a fixed version than how can it be said that ALL versions are vulnerable?
  ALL versions prior to the just-released fix are vulnerable, which means all versions actually in use when the announcement (simultaneous with the release of the fix) was made.
Real men by xorro · 2013-01-03 07:14 · Score: 1

Real men write server-side cgis in assembly
There is an upside by SuperKendall · 2013-01-03 08:17 · Score: 5, Funny

Thanks to this vulnerability, I was able to edit every Web2.0 website and change the color scheme from gray-on-gray to something readable. And I reduced the font size 10-20 points.
You can thank me later.

--
"There is more worth loving than we have strength to love." - Brian Jay Stanley
1. Re:There is an upside by Anonymous Coward · 2013-01-09 05:36 · Score: 0
  
  thanks
That's NOT disproving my points... apk by Anonymous Coward · 2013-01-03 10:02 · Score: 0

Running a DNS server, for what? To add complexity & waste electricity on a SEPARATE system here?? NO thanks...
OR
Even running it as a service on my single system here (wasting memory, CPU cycles, & RAM + other forms of I/O too), for doing what a TIGHTLY INTEGRATED part of the IP stack already does in a custom hosts file does already??
Again - no thanks!
* Besides - DNS does have issues in redirection DNS poisoning as well (in recursive mode and odds are you HAVE to set it up that way)... yes, you can point to the roots, but it's not like those CAN'T be floored too (that's a possible).
I don't have DNS, I use them myself... however, I use specialized FILTERING ones (vs malicious exploits) from the list below:
Norton DNS:
http://setup.nortondns.com/
198.153.192.1
198.153.194.1
198.153.192.60
198.153.194.60
198.153.192.50
198.153.194.50
198.153.192.40
198.153.194.40
OpenDNS:
http://www.opendns.com/home-solutions/
208.67.222.222
208.67.220.220
ScrubIT DNS:
http://scrubit.com/
67.138.54.100
207.225.209.66
Comodo Secure DNS:
http://www.comodo.com/secure-dns/switch/windows_vista.html
8.26.56.26
8.20.247.2
APK
P.S.=> Disprove the list of points that custom hosts files give you that are in the link to my program... go for it (you obviously can't & that's that)...
... apk
I'll make the same challenge to ANY ac troll by Anonymous Coward · 2013-01-03 10:09 · Score: 0

"Rinse, Lather, & Repeat" -> http://it.slashdot.org/comments.pl?sid=3355839&cid=42467837
FACT: So far, in my 8++ yrs. around here? There isn't a SINGLE ONE OF YOU that's managed to disprove the list of points I wrote enumerated in the link below, as to what custom hosts files can do that's GOOD on a number of levels, for end users of them:
---
APK Hosts File Engine 5.0++:
http://start64.com/index.php?option=com_content&view=article&id=5851:apk-hosts-file-engine-64bit-version&catid=26:64bit-security-software&Itemid=74 ?
---
* When you can manage to disprove that custom hosts file usage does ALL of those points for end users of them? THEN, you've made a point... otherwise?
LMAO @ U!
APK
P.S.=> Since you'd be just another AC troll (who has a registered 'luser' account but that I've dusted before on this very topic many times no doubt & you don't want those previous defeats tossed back in your face again, by "yours truly" on this very subject)...
... apk
Addendum: What if your DNS server goes down? by Anonymous Coward · 2013-01-03 10:15 · Score: 0

Then what??
So much for running your own DNS server!
Either:
A.) As a separate system, it's a waste of POWER (do you pay a power bill yourself?))
OR
B.) If you run it on the same SINGLE system you have, then, you're wasting CPU cycles, RAM, & other forms of I/O on what a TIGHTLY INTEGRATED part of the IP stack can do, that you can have on ANY system (or keep your custom hosts on a USB stick for that, machine to machine)...
Either way, you're adding complexity, & electricity usage, and introducing failure possibles like power outages or code failures downing it, & also DNS redirect poisonings too being another failure possible as well (in recursive mode you face that as a possible too).
APK
P.S.=> What if it gets "DNS poisoned" redirected too??? Then what????
... apk
Re:Online Income by Anonymous Coward · 2013-01-03 11:01 · Score: 0

A Chrysler?
"Take the train", troll by Anonymous Coward · 2013-01-03 11:02 · Score: 0

Right here -> http://it.slashdot.org/comments.pl?sid=3355839&cid=42467921
* :)
(Good Luck vs. that challenge - You'll NEED it!)
APK
P.S.=> Fact - Not a SINGLE ONE of you ac trolls here for 8++ yrs. has disproven my points on hosts files, as to the myriad number of GOOD THINGS they can do for a user on a plethora of levels - hence, my wishing you luck!
... apk
WTF? It's obvious what I stated... apk by Anonymous Coward · 2013-01-03 11:07 · Score: 0

Defensive measures you take vs. SQL Injection -> http://it.slashdot.org/comments.pl?sid=3355839&cid=42463653
* Seems all you WORMS have is a downmod vs. what I wrote there... because those ARE GOOD PRACTICES & also what I suspected might be wrong (I didn't read the article, I merely put out best practices that tend to work vs. SQL Injection in general).
APK
P.S.=> Then, there's this too as well, for the ac trolls that attempt to harass me via their stalking ac posts nigh constantly on hosts files as well -> http://it.slashdot.org/comments.pl?sid=3355839&cid=42467921 - it's a challenge none of them EVER "face up to" or defeat me on, in nearly 8++ yrs. of my posting here... lol!
... apk
Justify the downmod of my post, trolls... apk by Anonymous Coward · 2013-01-03 11:10 · Score: 0

I put out good generic best practices to use vs. SQL Injection, & "the best you've got", is a downmod of my post?
* LOL, please...
APK
P.S.=> Resorting to "the last resort" of trolls is WEAK of you, but then? Perhaps I expect too much & BETTER, from the likes of the trolls that infest this website's forums... lol!
... apk
Performance problem by Drunkulus · 2013-01-03 12:36 · Score: 1

I tried running the exploit but activerecord chewed up all the system memory and the oomkiller took the server down. Luckily my server restart cron script runs every minute so my social media aggregator startup, disruptr.com, is back online.
78 of your /. peers disagree (argue w/ them) by Anonymous Coward · 2013-01-03 13:47 · Score: 0

"The hosts file edits you do are considered a "hacked up" non-solution. The wrong way to do things. It's not what the hosts file is intended for." - by Anonymous Coward on Thursday January 03, @01:43PM (#42464951)
Oh, really? See my subject-line above & this list of your peers' findings regarding custom hosts files usage:
---
77++ SLASHDOT USERS EXPERIENCING SUCCESS USING HOSTS FILES QUOTED VERBATIM:
---

"I want my surfing speed back so I block EVERY fucking ad. i.e. http://someonewhocares.org/hosts/ and http://winhelp2002.mvps.org/hosts.htm FTW" - by UnknownSoldier (67820) on Tuesday December 13, @12:04PM (#38356782)

"this is not a troll, which hosts file source you recommend nowadays? it's a really handy method for speeding up web and it works." - by gl4ss (559668) on Thursday March 22, @08:07PM (#39446525)

"I use a custom /etc/hosts to block ads... my file gets parsed basically instantly ... So basically, for any modern computer, it has zero visible impact. And even if it took, say, a second to parse, that would be more than offset by the MANY seconds saved by not downloading and rendering ads. I have noticed NO ill effects from running a custom /etc/hosts file for the last several years. And as a matter of fact I DO run http servers on my computers and I've never had an /etc/hosts-related problem... it FUCKING WORKS and makes my life better overall." - by sootman (158191) on Monday July 13 2009, @11:47AM (#28677363)

"I actually went and downloaded a 16k line hosts file and started using that after seeing that post, you know just for trying it out. some sites load up faster." - by gl4ss (559668) on Thursday November 17, @11:20AM (#38086752)

"Ever since I've installed a host file (http://www.mvps.org/winhelp2002/hosts.htm) to redirect advertisers to my loopback, I haven't had any malware, spyware, or adware issues. I first started using the host file 5 years ago." - by TestedDoughnut (1324447) on Monday December 13, @12:18AM (#34532122)

"Better than an ad blocker, imo. Hosts file entries: http://www.mvps.org/winhelp2002/hosts.htm " - by TempestRose (1187397) on Tuesday March 15, @12:53PM (#35493274)

"^^ One of the many reasons why I like the user-friendliness of the /etc/hosts file." - by lennier1 (264730) on Saturday March 05, @09:26PM (#35393448)

"They've been on my HOSTS block for years" - by ScottCooperDotNet (929575) on Thursday August 05 2010, @01:52AM (#33147212)

"I'm currently only using my hosts file to block pheedo ads from showing up in my RSS feeds and causing them to take forever to load. Regardless of its original intent, it's still a valid tool, when used judiciously." - by Bill Dog (726542) on Monday April 25, @02:16AM (#35927050)

"you're right about hosts files" - by drinkypoo (153816) on Thursday May 26, @01:21PM (#36252958)

"APK's monolithic hosts file is looking pretty good at the moment." - by Culture20 (968837) on Thursday November 17, @10:08AM (#38085666)

"I also use the MVPS ad blocking hosts file." - by Rick17JJ (744063) on Wednesday January 19, @03:04PM (#34931482)

"I use ad-Block and a hostfile" - by Ol Olsoc (1175323) on Tuesday March 01, @10:11AM (#35346902)

"I do use Hosts, for a couple fake domains I use." - by
Overloaded Dev by Faisal+Rehman · 2013-01-04 05:16 · Score: 0

May be developers are less and work required is more.