3 ms·

...and the first thing that happens when it ever happens to be connected to the internet is that it gets broken and has to be rewritten. That's why it's good to

by d33 10y ago

...and the first thing that happens when it ever happens to be connected to the internet is that it gets broken and has to be rewritten. That's why it's good to care about the quality in the first place...

nostrademons 10y ago
Chances are that if you're connecting a formerly in-house application to the Internet, you want to force a rewrite. It likely has a lot of other security vulnerabilities that would let an attacker pwn your corporate network. You build software for the open Internet very differently from you build it for a trusted environment; you don't want to fool yourself into thinking the latter is good enough for the former.
- d33 10y ago
  What are the differences really? What's a "trusted environment" anyway?
  - nostrademons 10y ago
    Every program needs to make some assumptions about what operations it's going to trust and what it's going to verify. Most programs, for example, assume that (length + 1) [where 'length' is a simple 32-bit integer] will have no side effects, even though there's no absolute guarantee that the NSA hasn't backdoored your compiler or a Chinese supplier hasn't backdoored your CPU to open a rooted shell remotely. Most programs will also assume that (length + 1 > length), even though in many languages this isn't universally true because of integer overflow. If your program never deals with integers that large, it doesn't matter. For most public programs, the trust boundary is generally assumed to be the process. Any I/O the process does is assumed to be untrusted; it could do anything. But anything inside the process is assumed to work as the language says it does, because the OS is assumed to provide memory protection that prevents other processes from tampering with it. (Some big companies go a step further and dictate that you're not to trust 3rd-party libraries unless the code has been specifically audited; this is generally a sensible practice security-wise, but a huge drag on developer velocity.) If you couldn't trust the basic machine operators, you'd never get anything done - you'd have to write sanity checks everywhere, and then you have no guarantee that the sanity checks themselves aren't backdoored. For many internal apps, the network is inside the trust boundary. It's assumed that any network connection comes from a trusted source, because otherwise the firewall would've rejected this. And being able to assume this saves a lot in developer velocity; it becomes feasible to write one-off internal tools without the devs having to carefully audit all the I/O & cross-process code for vulnerabilities. If you didn't have this trust, most of these apps wouldn't get written, because the productivity benefit they provide isn't greater than the cost of writing a hardened, secure system. It's not just networking calls; if you can assume that your users are non-malicious employees, you also don't need to worry about XSS or XSRF, pathological regexps, DOS attacks based on large payloads, etc.
    - deleted 10y ago
      [deleted]
    - jacobush 10y ago
      And sometimes you don't trust the operations. I've heard tales of flight computer software running on 3 computers from 3 vendors running 3 implementations of software from 3 independent teams. Then the 3 computers voted on a course of action.
      - aaronmdjones 10y ago
        You may be interested in this PDF[1] which describes what you're talking about. Title: Triple-Triple Redundant 777 Primary Flight Computer [1] http://www.citemaster.net/get/db3a81c6-548e-11e5-9d2e-00163e009cc7/R8.pdf&usg=AFQjCNE62Hljkun5iNMCKl7-dqrzw5D_UQ&bvm=bv.141320020,d.d2s http://www.citemaster.net/get/db3a81c6-548e-11e5-9d2e-00163e...
        jacobush 10y ago
        Thank you. I heard it about SAAB Gripen fighter/attack/recon craft in the 90s, but for me it's faded memory of hearsay - so it's cool to read a more substantial reference. :)
mannykannot 10y ago
That's the best-realistic-case scenario. The most likely case is that even if a few problems are found and patched, some serious vulnerabilities will be left in place, unnoticed until someone from outside, without your interests at heart, goes looking for them.

by d33 10y ago

nostrademons 10y ago

Chances are that if you're connecting a formerly in-house application to the Internet, you want to force a rewrite. It likely has a lot of other security vulnerabilities that would let an attacker pwn your corporate network. You build software for the open Internet very differently from you build it for a trusted environment; you don't want to fool yourself into thinking the latter is good enough for the former.

d33 10y ago
What are the differences really? What's a "trusted environment" anyway?
- nostrademons 10y ago
  Every program needs to make some assumptions about what operations it's going to trust and what it's going to verify. Most programs, for example, assume that (length + 1) [where 'length' is a simple 32-bit integer] will have no side effects, even though there's no absolute guarantee that the NSA hasn't backdoored your compiler or a Chinese supplier hasn't backdoored your CPU to open a rooted shell remotely. Most programs will also assume that (length + 1 > length), even though in many languages this isn't universally true because of integer overflow. If your program never deals with integers that large, it doesn't matter. For most public programs, the trust boundary is generally assumed to be the process. Any I/O the process does is assumed to be untrusted; it could do anything. But anything inside the process is assumed to work as the language says it does, because the OS is assumed to provide memory protection that prevents other processes from tampering with it. (Some big companies go a step further and dictate that you're not to trust 3rd-party libraries unless the code has been specifically audited; this is generally a sensible practice security-wise, but a huge drag on developer velocity.) If you couldn't trust the basic machine operators, you'd never get anything done - you'd have to write sanity checks everywhere, and then you have no guarantee that the sanity checks themselves aren't backdoored. For many internal apps, the network is inside the trust boundary. It's assumed that any network connection comes from a trusted source, because otherwise the firewall would've rejected this. And being able to assume this saves a lot in developer velocity; it becomes feasible to write one-off internal tools without the devs having to carefully audit all the I/O & cross-process code for vulnerabilities. If you didn't have this trust, most of these apps wouldn't get written, because the productivity benefit they provide isn't greater than the cost of writing a hardened, secure system. It's not just networking calls; if you can assume that your users are non-malicious employees, you also don't need to worry about XSS or XSRF, pathological regexps, DOS attacks based on large payloads, etc.
  - deleted 10y ago
    [deleted]
  - jacobush 10y ago
    And sometimes you don't trust the operations. I've heard tales of flight computer software running on 3 computers from 3 vendors running 3 implementations of software from 3 independent teams. Then the 3 computers voted on a course of action.
    - aaronmdjones 10y ago
      You may be interested in this PDF[1] which describes what you're talking about. Title: Triple-Triple Redundant 777 Primary Flight Computer [1] http://www.citemaster.net/get/db3a81c6-548e-11e5-9d2e-00163e009cc7/R8.pdf&usg=AFQjCNE62Hljkun5iNMCKl7-dqrzw5D_UQ&bvm=bv.141320020,d.d2s http://www.citemaster.net/get/db3a81c6-548e-11e5-9d2e-00163e...
      - jacobush 10y ago
        Thank you. I heard it about SAAB Gripen fighter/attack/recon craft in the 90s, but for me it's faded memory of hearsay - so it's cool to read a more substantial reference. :)

mannykannot 10y ago

That's the best-realistic-case scenario. The most likely case is that even if a few problems are found and patched, some serious vulnerabilities will be left in place, unnoticed until someone from outside, without your interests at heart, goes looking for them.