171–180 of 294 posts
Earlier quoted context omitted.
Posting the gory details this early on is not a nice thing to do. It's probably best to hold off for a while until everyone has had a reasonable chance to upgrade.
Do you think not selling guns on an open market stops criminals from obtaining them as well?
Patch right now.
Why doesn't Ruby (and Python and all other languages) have Perl's tainting built in and always running? I'm not advocating it as the only security mechanism, but rather as another barrier to be overcome just like address-space-randomisation, data-exection prevention and all the rest... (Haven't Google recently shared a valgrind-lite runtime bounds checker which is being incorporated into GCC etc? Might lead the way o…
Because tainting is an inherently flawed way to do security. Blacklisting capabilities/methods/data always leaves holes behind, and it's nearly impossible to secure a system using tainting alone. Even the Perl folks say it shouldn't be used as a security mechanism...it should be used to help thin out security issues during development and testing. If you want to secure a system...whitelist, don't blacklist.
Earlier quoted context omitted.
As there have been many exploits / issues recently realized in parameters parsing, why isn't there more of a focus on security here? Specifically, this is where users/hackers can put ANY DARN THING THEY WANT and your server has to deal with it. As a simple solution, one could pass a signed auth-hash of the fields generated by form_for, and the server could re-hash the fields submitted to ensure the form data you aske…
> why isn't there more of a focus on security here? More compared to what, exactly? This vulnerability was responded to pretty damn quickly after it was reported, given that almost nobody is even paid to work on Rails. If you saw Aaron tweeting about "working over the weekend" a few days ago, well, now you know. That said, you mention attr_accessible in your post: that's gone as of the next release of Rails. Basicall…
1. Keep this link bookmarked. 2. Pull it off next time someone starts with the 'test-replace-static-typing' argument. 3. WIN
Earlier quoted context omitted.
Posting the gory details this early on is not a nice thing to do. It's probably best to hold off for a while until everyone has had a reasonable chance to upgrade.
Do you think not selling guns on an open market stops criminals from obtaining them as well?
We've now officially captured both sides of the argument and can safely move on.
Github.com (built on Rails) is currently having issues. If I had a tin foil hat, I'd put it on. Hopefully their issues are not related to this vulnerability.
Earlier quoted context omitted.
Getting continuous errors on deploy during the bundle stage like so: /usr/lib/ruby/1.9.1/rubygems/remote_fetcher.rb:215:in `fetch_http': bad response Not Found 404 (http://bb-m.rubygems.org/quick/Marshal.4.8/activesupport-3.2.11.gemspec.rz) Is this because rubygems.org is being nailed?
This is a mirror, so that's why it's probably out of date...can you try just production.cf.rubygems.org ? I have heard zero reports of downtime or other issues. :/ http://uptime.rubygems.org/131647
$ cd && bundle install --gemfile Gemfile --path /bundle --without development test
1. Keep this link bookmarked. 2. Pull it off next time someone starts with the 'test-replace-static-typing' argument. 3. WIN
1. This class of problems is not unique to Ruby.
2. Similar problems have been identified in Struts, and python's pickle.
3. Specifically in this case, YAML.load() can deserialize unintended object types. In the case of Struts the problem was the expression library used can also deserialize unintended object types (like File), plus setting properties on these types can have side effects (such as dropping files into your system).
4. I took a look at Microsoft's WCF. The DataContractSerializer states that it only is allowed to load types that are specified by a contract. http://msdn.microsoft.com/en-us/library/vstudio/ms733135(v=v... This should be the gold standard. In addition, it warns that even loading XML documents can be dangerous if we then load remote DTDs for validation.
5. For the old salts, remoting or RMI have similar issues - both mitigated by restricting the types that can be deserialized. http://msdn.microsoft.com/en-us/library/5dxse167(v=vs.71).as...
6. Here's another vulnerability which targets serialization http://wouter.coekaerts.be/2011/spring-vulnerabilities
In summary,
1. all deserializers should be viewed with suspicion.
2. A deserializer which does not implement a whitelist of types that it can deserialize to is not suited for handling arbitrary data.
3. For example, it is capable to creating untainted/trusted objects in application servers, which some time later, may be used for XSS, or execution in SQL. In the Struts case, the standard Java libraries have constructors and methods that deserializing is enough to result in an arbitrary file being dropped on the remote file system.