6 ms·

I've grouped the patches for 4.1 and 4.2 here: https://drive.google.com/file/d/0BwnrE2iUdypUMkpqWVVPTXNzNVU/view https://drive.google.com/file/d/0BwnrE2iUdypUMk

I've grouped the patches for 4.1 and 4.2 here: https://drive.google.com/file/d/0BwnrE2iUdypUMkpqWVVPTXNzNVU/view https://drive.google.com/file/d/0BwnrE2iUdypUMkpqWVVPTXNzNVU... -- because download one by one is boring. Don't trust me, verify each file before patching. Some comments: [CVE-2015-7581] Object leak vulnerability for wildcard controller routes in Action Pack: Look for routes that contain ":controller" and change it to something else. Hopefully you didn't have this weird name in your routes. [CVE-2015-7578/79] Possible XSS vulnerability in rails-html-sanitizer: You're safe if you use a single page application that properly encode for you. Stripping tags isn't the best way anyway to filter XSS, so if you're encoding, you're good. [CVE-2016-0753] Possible Input Validation Circumvention in Active Model: params.permit! is negligence, you should not be doing that anyway [CVE-2016-0752] Possible Information Leak Vulnerability in Action View: render params[:id] is not defensive programming, so you should not be doing that too [CVE-2015-7577] Nested attributes rejection proc bypass in Active Record: Only if using nested_attributes and rejection proc. Wasn't my case. Just patch. [CVE-2016-0751] Possible Object Leak and Denial of Service attack in Action Pack: DoS is bad, just patch. [CVE-2015-7576] Timing attack vulnerability in basic authentication in Action Controller: Just patch. -- Doesn't look THAT bad, but need to be patched fast.

Someone1234 11y ago
Wow you have a terrible attitude about security. "None of these are an issue, just program in this [very specific way that requires pre-knowledge of these vulnerabilities] and you're safe, anything else is basically negligence." Your opinions about rails-html-sanitizer are particularly troubling as even if you use the sanitizer as suggested in the docs you're vulnerable and your retort is "well you should encode AND sanitise, not just rely on the sanitiser doing what the documentation says it should do!" Why? I have no issue with the wording in the official CVEs. But this attempt at whitewashing the, frankly, pretty serious issues is deplorable.
- andersonmvd 11y ago
  Some programming styles are not defensive from a security perspective. As a programmer one should acknowledge that using "render" passing a param right from the request, without validating it, is not a good thing, right? That's my point. Some issues here can be solved just by taking the right approach, but won't solve for all of them, of course. XSS mitigation works better with encoding rather than sanitization. If you want me to explain I explain. But hey, you won't do any good complaining in face of this situation. Time to help people fix it. Peace.
  - Alex3917 11y ago
    I mean ideally you should 1) strip tags 2) encode 3) use X-XSS headers 4) use CSP headers. That way if any one of these fails, the others will catch it. That said, there still shouldn't be security holes in the framework.
    - andersonmvd 11y ago
      Well said, I agree.
    - minitech 11y ago
      Stripping tags before encoding is security theatre. Encoding is just replacing 2–4 characters; if it’s not implemented properly, there’s no way tag stripping is.
- matthewmacleod 11y ago
  Calm down a bit! The implication I take from the person you are responding to is not that the vulnerabilities don't matter, but that it's useful to reflect on them and make sure that you are always programming defensively.
  - Someone1234 11y ago
    They went through most of the issues and shifted blame for the issue from Rails to the developer/user. "Hopefully you didn't have this weird name in your routes." "Stripping tags isn't the best way anyway to filter XSS, so if you're encoding, you're good." "is negligence, you should not be doing that anyway" "is not defensive programming, so you should not be doing that too" It isn't "reflecting" it is blame shifting. And there's a huge difference between defensive programming and being psychic, in this case it is more the latter, as even features like the sanitiser we should have known better than to use as the docs tell us to.
    - toolz 11y ago
      Stop making this about ego. The person was helping developers secure their apps and you're trying to make this about who is wrong. Making sure someone feels bad in the open source community won't make anything better.
      - phamilton 11y ago
        MINASWAN https://en.wikipedia.org/wiki/MINASWAN https://en.wikipedia.org/wiki/MINASWAN
- eropple 11y ago
  I have a much bigger problem with your post than his--and calling him out for a "terrible attitude" regarding security is a little bit funny seeing as he runs Gauntlet.io, which while not my favorite scanner out there is a legit tool that deserves more respect than you have afforded him. He has his bona fides; where are yours? And, more concretely, I have no problem with his pointing out that some of--not all, but some--these issues are ones mitigated by decent, security-aware software development practices, like, oh, "don't spit something into a template out of your input parameters". Because tools break. Your libraries break. They will always break. Program defensively in all situations where hostile input is possible and never take for granted any attempts to defuse attacks; always favor braces-and-belt wherever possible and you'll generally do okay. It's entirely unnecessary to be a jerk towards him for saying this.
  - Someone1234 11y ago
    > He has his bona fides; where are yours? I called him out for his specific replies in this specific thread. I didn't call out his reputation or character. Maybe you should stick to what they and I actually posted here today, and not try to draw the conversation off track into reputation wars. > It's entirely unnecessary to be a jerk towards him for saying this. I don't appreciate being called a "jerk." I stand by what I said, and what I said was that I felt (and feel) that they have a bad attitude to security. They're trying to shift blame from the rails developers to every rails user, and their excuses are weak. If you think that is "jerky," that's fine, but I feel like name calling and playing the reputation card for no reason is only going to take a conversation down a bad and unconstructive path.
    - enraged_camel 11y ago
      >>I don't appreciate being called a "jerk Then try not to sound like one? The OP went out of his way to compile and document the important bugs and post them here. You, on the other hand, completely ignored the value of his contribution and instead rudely called him out on a very minor (and frankly, subjective) tonal issue, and went so far as to call it "whitewashing," which implies that he has an agenda.
- rst 11y ago
  More like "avoid these particular, obviously risky constructs, which any good security scanner will call out as high-priority trouble spots". The two particular constructs he warns against ("render params" and permit! followed by mass assignment) will both get high-priority warnings from Brakeman.
- warfangle 11y ago
  But Rails Culture is to make developers smile! Fixing security vulnerabilities and writing docs that actually reflect best security practices do not make developers smile. And accusing to have a terrible attitude does not make a developer smile either, so this is obviously your fault! /s
eganist 11y ago
> [CVE-2015-7578/79] Possible XSS vulnerability in rails-html-sanitizer: You're safe if you use a single page application that properly encode for you. Stripping tags isn't the best way anyway to filter XSS, so if you're encoding, you're good. So uh, what if your application is taking an input that's then parsed by another application with poor output encoding? Granted, the application that's properly encoding for the correct context is good, but any applications which don't do that but also use that same dataset are screwed because your application didn't perform proper input validation. Defense in depth strategies exist for a reason. Input validation, output encoding for every single context (this includes using angular properly, for instance), anti-xss headers, CSP, the list goes on. These aren't all prescribed just to protect that one application. They're prescribed so that when applied correctly across all apps, they're all protected from negligence in one app harming the data.
- andersonmvd 11y ago
  Indeed, "any applications which don't do that but also use that same dataset are screwed". You're totally right. I didn't specify whether the encoded string is persisted or not. You considered that it isn't, which leads to the application with poor controls that you mentioned. Nice point. You're also right about defense in depth. I just wanted to highlight when an approach can be dangerous. That's one example, but there are others such as misuse of eval, constantize, etc. If the developer be aware of such risks and implement properly, even some (not all of course) newly disclosed vulnerabilities won't affect the application.
  - eganist 11y ago
    Yup to all others you mentioned. I usually just teach about why trust matters and how to think about it as a developer. Works out well with training the devs at my current workplace. Back to your comments on the CVEs, the reason I replied the way I did was because your comments appeared to come across as being the only necessary mitigations per-se. I know that's not at all how you intended it ("some comments" as opposed to "how to mitigate"), but my first pass over the text made me feel that way about it. In any case, nice chat. I like productive exchanges.
tomc1985 11y ago
As an everyday Rails user, most of these aren't really that surprising. Sure, one could cite 'defensive programming' or whatever, but a lot of these behaviors are warned against in the documentation.
- eric_h 11y ago
  and static analyzers would yell at you for one or two of them, too

Someone1234 11y ago

Wow you have a terrible attitude about security. "None of these are an issue, just program in this [very specific way that requires pre-knowledge of these vulnerabilities] and you're safe, anything else is basically negligence." Your opinions about rails-html-sanitizer are particularly troubling as even if you use the sanitizer as suggested in the docs you're vulnerable and your retort is "well you should encode AND sanitise, not just rely on the sanitiser doing what the documentation says it should do!" Why? I have no issue with the wording in the official CVEs. But this attempt at whitewashing the, frankly, pretty serious issues is deplorable.

andersonmvd 11y ago
Some programming styles are not defensive from a security perspective. As a programmer one should acknowledge that using "render" passing a param right from the request, without validating it, is not a good thing, right? That's my point. Some issues here can be solved just by taking the right approach, but won't solve for all of them, of course. XSS mitigation works better with encoding rather than sanitization. If you want me to explain I explain. But hey, you won't do any good complaining in face of this situation. Time to help people fix it. Peace.
- Alex3917 11y ago
  I mean ideally you should 1) strip tags 2) encode 3) use X-XSS headers 4) use CSP headers. That way if any one of these fails, the others will catch it. That said, there still shouldn't be security holes in the framework.
  - andersonmvd 11y ago
    Well said, I agree.
  - minitech 11y ago
    Stripping tags before encoding is security theatre. Encoding is just replacing 2–4 characters; if it’s not implemented properly, there’s no way tag stripping is.
matthewmacleod 11y ago
Calm down a bit! The implication I take from the person you are responding to is not that the vulnerabilities don't matter, but that it's useful to reflect on them and make sure that you are always programming defensively.
- Someone1234 11y ago
  They went through most of the issues and shifted blame for the issue from Rails to the developer/user. "Hopefully you didn't have this weird name in your routes." "Stripping tags isn't the best way anyway to filter XSS, so if you're encoding, you're good." "is negligence, you should not be doing that anyway" "is not defensive programming, so you should not be doing that too" It isn't "reflecting" it is blame shifting. And there's a huge difference between defensive programming and being psychic, in this case it is more the latter, as even features like the sanitiser we should have known better than to use as the docs tell us to.
  - toolz 11y ago
    Stop making this about ego. The person was helping developers secure their apps and you're trying to make this about who is wrong. Making sure someone feels bad in the open source community won't make anything better.
    - phamilton 11y ago
      MINASWAN https://en.wikipedia.org/wiki/MINASWAN https://en.wikipedia.org/wiki/MINASWAN
eropple 11y ago
I have a much bigger problem with your post than his--and calling him out for a "terrible attitude" regarding security is a little bit funny seeing as he runs Gauntlet.io, which while not my favorite scanner out there is a legit tool that deserves more respect than you have afforded him. He has his bona fides; where are yours? And, more concretely, I have no problem with his pointing out that some of--not all, but some--these issues are ones mitigated by decent, security-aware software development practices, like, oh, "don't spit something into a template out of your input parameters". Because tools break. Your libraries break. They will always break. Program defensively in all situations where hostile input is possible and never take for granted any attempts to defuse attacks; always favor braces-and-belt wherever possible and you'll generally do okay. It's entirely unnecessary to be a jerk towards him for saying this.
- Someone1234 11y ago
  > He has his bona fides; where are yours? I called him out for his specific replies in this specific thread. I didn't call out his reputation or character. Maybe you should stick to what they and I actually posted here today, and not try to draw the conversation off track into reputation wars. > It's entirely unnecessary to be a jerk towards him for saying this. I don't appreciate being called a "jerk." I stand by what I said, and what I said was that I felt (and feel) that they have a bad attitude to security. They're trying to shift blame from the rails developers to every rails user, and their excuses are weak. If you think that is "jerky," that's fine, but I feel like name calling and playing the reputation card for no reason is only going to take a conversation down a bad and unconstructive path.
  - enraged_camel 11y ago
    >>I don't appreciate being called a "jerk Then try not to sound like one? The OP went out of his way to compile and document the important bugs and post them here. You, on the other hand, completely ignored the value of his contribution and instead rudely called him out on a very minor (and frankly, subjective) tonal issue, and went so far as to call it "whitewashing," which implies that he has an agenda.
rst 11y ago
More like "avoid these particular, obviously risky constructs, which any good security scanner will call out as high-priority trouble spots". The two particular constructs he warns against ("render params" and permit! followed by mass assignment) will both get high-priority warnings from Brakeman.
warfangle 11y ago
But Rails Culture is to make developers smile! Fixing security vulnerabilities and writing docs that actually reflect best security practices do not make developers smile. And accusing to have a terrible attitude does not make a developer smile either, so this is obviously your fault! /s

eganist 11y ago

> [CVE-2015-7578/79] Possible XSS vulnerability in rails-html-sanitizer: You're safe if you use a single page application that properly encode for you. Stripping tags isn't the best way anyway to filter XSS, so if you're encoding, you're good. So uh, what if your application is taking an input that's then parsed by another application with poor output encoding? Granted, the application that's properly encoding for the correct context is good, but any applications which don't do that but also use that same dataset are screwed because your application didn't perform proper input validation. Defense in depth strategies exist for a reason. Input validation, output encoding for every single context (this includes using angular properly, for instance), anti-xss headers, CSP, the list goes on. These aren't all prescribed just to protect that one application. They're prescribed so that when applied correctly across all apps, they're all protected from negligence in one app harming the data.

andersonmvd 11y ago
Indeed, "any applications which don't do that but also use that same dataset are screwed". You're totally right. I didn't specify whether the encoded string is persisted or not. You considered that it isn't, which leads to the application with poor controls that you mentioned. Nice point. You're also right about defense in depth. I just wanted to highlight when an approach can be dangerous. That's one example, but there are others such as misuse of eval, constantize, etc. If the developer be aware of such risks and implement properly, even some (not all of course) newly disclosed vulnerabilities won't affect the application.
- eganist 11y ago
  Yup to all others you mentioned. I usually just teach about why trust matters and how to think about it as a developer. Works out well with training the devs at my current workplace. Back to your comments on the CVEs, the reason I replied the way I did was because your comments appeared to come across as being the only necessary mitigations per-se. I know that's not at all how you intended it ("some comments" as opposed to "how to mitigate"), but my first pass over the text made me feel that way about it. In any case, nice chat. I like productive exchanges.

tomc1985 11y ago

As an everyday Rails user, most of these aren't really that surprising. Sure, one could cite 'defensive programming' or whatever, but a lot of these behaviors are warned against in the documentation.

eric_h 11y ago
and static analyzers would yell at you for one or two of them, too