bikkel|watje.org

default security responses

Posted on Jan 1, 0001

Dear Submitter,

We would like to thank you for the efforts you made in reporting this issue, but we’re afraid we can’t honor this as a valid bug-report.

The kind of bug you’re reporting is a:

  • content injection attack
  • XSS attack
  • ‘missing features’ thingy (HSTS, X-XSS, DKIM, SPF, etc)
  • set header because browser X is crappy and doing stupid, insecure things (X-Content-Type-Options,etc) report
  • I think you should do X advisory
  • valid bug
  • Behavior that is there for a real purpose
  • information disclosure report
  • valid bug if it was exploitable on our platform
  • Theoretical behavior that’s not exploitable in the real world (TM)
  • Disclosure of info that might be used during the reconnaissance stage

The reason for not honoring the bug is that:

  • The behavior is not a bug, it something that could be a precursor to a bug.
  • Our bug bounty program is only valid for our systems, not for systems of our customers.
  • a valid SPF record that permits soft-fail is correct usage of the SPF standard, and therefore not a bug or vulnerability, but simply policy
  • disclosure of what version of what software is running is almost always default behavior, and although it might make it easier to use a automatic attack script, the disclosure itself is not a bug
  • content-injection is not a real issue unless XSS and/or HTML injection is possible
  • it’s the responsibility of the browser to make sure it does ‘the right thing’, even if the behavior can be mitigated by adjusting the server or DNS.
  • if you would have actually tested it, you would have known it’s not exploitable
  • the lack of extra, optional hardening (or “opt-in security enhancement”) is not a bug or vulnerability
  • yes, we could have set this DNS record, but why bother? It’s not going to improve security
  • Disclosure of info that might be used for a optional attack is not a vulnerability in itself
  • it’s not exploitable
  • you’re wrong

We would also like to point out that:

  • if this where a valid bug, then the internet or WWW as we know it wouldn’t exist / couldn’t function
  • Google, Bing, Yahoo, Facebook, etc. are also vulnerable to this “bug”. Why don’t you try to convince them first?
  • This is dumb behavior of the browser, please file a bug with the browser vendor
  • the fact that somebody said somewhere in a wiki that this is a bug doesn’t make it a real, exploitable bug
  • this only works if a MITM attack is possible, which is unlikely, since the entire connection is encrypted
  • the fact that MS screwed up big time in not simply honoring the mime-type the server send back, and introduced X-Content-Type-Options to let the server say that the browser should behave as it should behave in the first place is not a server bug.
  • the fact that the client software vendor won’t pay for this bug doesn’t mean we’re willing to pay for it
  • if this was as serious as you say it is, the entire internet would be vulnerable
  • the CERT’s didn’t think it was necessary to warn for this and the NSA/CIA/KGB/FSB/hackingteam/Fancy Bear/Ghostnet (etc,etc) are not using this. We wonder why
  • the behavior you think is a bug is actually the default behavior of the software. If you think this is a bug, please contact the authors of the software.
  • the authors of the software don’t think its a security bug because it can’t be exploited in any way, and we agree
  • if literally every web-server in the world is vulnerable unless header X is set, then the default client-side settings are clearly wrong, and those defaults should be fixed
  • this can only be exploited by an attacker on the same physical network by saturation the ethernet connection for about a year before the key is sufficiently reduced to make an attack feasible. We think that this attack is really clever, but not really exploitable in the real world
  • the fact that somebody else paid money for reporting this through hackerone doesn’t make it a real, exploitable bug
  • We don’t know if a customer has it’s own bug reporting policy or bug bounty program
  • the author(s) of the RFC specifically addresses security concerns, and the consensus of the IETF is that the author(s) is/are correct.
  • the issue was already known, and additional measures had been taken to mitigate the issue. You would have known that if you had tested the issue before reporting it
  • the fact that you don’t like it or wouldn’t do it like this does not mean it’s a bug
  • Having a catch-all vhost is in itself not a bug. If a application running under it would blindly trust it, then that would be a bug.
  • it’s totally OK to use a automated tool to find vulnerabilities, but you have to make sure at a lower level that what it’s saying is actually correct. You can’t just say that it’s a problem, just because tool X says so
  • the issue you’re describing is only a bug if technology X is used in way Y, which is clearly not the case here
  • the simplest way to prove that something is a real bug is a proof-of concept attack on the system
  • silly fallback behavior will always be silly fallback behavior, no matter what headers you set. How do you get a HSTS header? By connection over a HTTP connection? In that case a MITM can strip out the HSTS header. And how long is the HSTS header valid? In short: The HSTS header is only valid for a short time, and useless for new connections to web-servers. The real solution is to make https the default protocol, and only use https if explicitly requested (don’t fall back to http unless another secure mechanism says so (dnssec)). A protocol that is only useful when a MITM is not interfering is not really useful against MITM attacks. (it’s actually worse, since it gives a false sense of security).
  • keeping on compensating for browser silly stuff is dangerous, since the default behavior of browsers is centrally set (by software vendors), but the ‘setting a header to do the right thing’ has to be done manually for every web-server, which is bound to be forgotten / missed, etc.
  • the correct behavior should be default. Insecure behavior should be explicitly enabled through headers / dns records, not the other way around.
  • The DNS record is actually here because this is a hard requirement of SIDN (Dutch domain TLD)
  • this idea / concept has been thoroughly debunked here: ………..

Finally you might consider that:

  • if it is a bug in software X, then why doesn’t it have a CVE?
  • the software name and version reported by the daemon are not really what it is saying it is.
  • the fact that it’s software version N, doesn’t mean that it’s not patched
  • in ‘the real world’(TM) there are many reasons why people do (or don’t do) things, and it’s not always laziness or incompetence
  • Silicon-Based Lifeforms are possible. Don’t be carbon-centric!
  • we don’t care what other people say is correct behavior. We make up our own mind
  • The number of people using a javascript enabled browser on a shared system is probably less then 10 (I haven’t seen it since 1997)
  • we are also Independent Web Security Researchers !!!
  • black swans actually exist
  • this : ………..