4 ms·

I don't know. I found the argument convincing that even naming the breach "identity theft" is beginning to push responsibility away from Equifax and make it see

I don't know. I found the argument convincing that even naming the breach "identity theft" is beginning to push responsibility away from Equifax and make it seem a personal problem of those affected, or a general societal phenomenon. When in reality it's just Equifax's poor security practices. As you probably know, the exploit basically is using Java's ability to dynamically execute code from JVM bytecodes (supplied via XML in this case, but that's just an implementation detail). Once you get remote code execution ability, it's game over for most Java backend apps, because these are executed in a single process/address space and thus lack basic process isolation. Even if JAAS were used to propagate authorization contexts within the Java backend, typically (almost always) Java apps operate in such a way that a single database identity/credential sets is used for any and all database access. Dynamic bytecode execution is a core feature of Java and other JIT execution environments, so you can't use straightforward NoExecute bits (provided by hardware and supported by OS loaders to disallow calling into dynamically allocated memory) to prevent this from happening, and can't contain/isolate execution paths with authorization contexts either. For these reasons, I think this breach should make banks and other financial institutions rethink their Java strategies mid- to long-term.

dboreham 9y ago
Ability to execute data as code is present in many languages. Almost all of them these days. I think you are saying that banks should only use C or C++ ??
- tannhaeuser 9y ago
  Or use other statically compiled languages instead. Or at least use Java or O/S sandboxing features. At least in the web-facing parts of their apps. In any case, this requires some planning ahead, and a mindset different from "agile". Maybe Java 9's AOT compilation can help in the process, but even if it could produce stand-alone programs, I think the dynamisms in Java code (reflection, annotations, dynamic class loaders) will make this infeasible for most code bases.
- wschroed 9y ago
  He is saying they should practice process isolation. Example architecture: https://cr.yp.to/qmail/guarantee.html https://cr.yp.to/qmail/guarantee.html
  - phamilton 9y ago
    He also suggests that even with process isolation in the application layer, the database is likely not going to be isolated and you'll be breached anyway. The qmail architecture would likely be very inefficient with 100M+ users.
- bunderbunder 9y ago
  I don't know Java well, but at least in .NET it's possible to set a flag that disable execution of dynamically emitted code. Obvs, you should do this on every box that accepts connections from the outside world. Obvs, it's no easier to get people to do this in practice than it is to get people to quit using string formatting to get parameters into their SQL queries.
  - tomrod 9y ago
    Make it opt out/default behavior.
- paulddraper 9y ago
  Buffer overflow
- mannykannot 9y ago
  DEP and ASLR provide significant mitigation of the threat posed by this capability in statically-compiled languages, so it is definitely an issue that should be considered, along with others. Having said that, it is unlikely that there is any merely technical solution for the problem, which arises from the whole system being predicated on a falsehood - the assumed confidentiality of SSNs.
- daxelrod 9y ago
  Programs in C and C++ can still execute data as code with buffer overflows. They're not a panacea either.
  - ithkuil 9y ago
    That's right, but the OP did mention how that issue is addressed in c/c++: > so you can't use straightforward NoExecute bits (provided by hardware and supported by OS loaders to disallow calling into dynamically allocated memory
skybrian 9y ago
Before getting too deep in to this, how do we know it had anything to do with injecting bytecode? It's not clear that's what the Struts bug was about.
- deleted 9y ago
  [deleted]
seedless_sensat 9y ago
Why is the top comment about the JVM? This has nothing to do with the article.
mindslight 9y ago
> I found the argument convincing that even naming the breach "identity theft" is beginning to push responsibility away from Equifax and make it seem a personal problem of those affected, or a general societal phenomenon. When in reality it's just Equifax's poor security practices. The thing being hidden isn't the surveillance bureau's poor security practices, but the banks who actually extend credit. Banks want to pretend that they can define identity as equivalent to a few bits of public information, and when they're defrauded blame innocent bystanders instead of their own broken abstraction.
curun1r 9y ago
There are two massive problems and neither of them have anything to do with executing attacker's code. First, for Equifax, their databases should be sufficiently isolated from front-end web servers. SQL gives you the ability to, in essence, ask the database any question the data can possibly answer. Instead, Equifax needs to do the work to enumerate all the questions they want the data to answer and put intermediate API services in place that answer only those questions. Public-facing web servers should only be allowed contact the intermediate API servers, and not the database. With data that has the value (to an attacker) that Equifax's database does, this is the minimum that needs to be done to offer reasonable security. Second, there's an identity problem. That identities can be stolen using largely facts about people (name, address and such and, yes, SSN) is a fundamental problem in how we identify people. They're using non-secrets in a way that assumes they are secret. A Keybase identity is much closer to the model that the industry needs to adopt. Chalking up the cause of this to flaws in some ancient Java web framework that's barely used anymore is just sweeping the true problems under the rug. The industry needs a fundamental overhaul to how they identify people and mandatory security compliance (hey...they foisted PCI-DSS on etailers and card processors, so they can't complain when something similar is foisted back on them) to keep our information safe.

dboreham 9y ago

Ability to execute data as code is present in many languages. Almost all of them these days. I think you are saying that banks should only use C or C++ ??

tannhaeuser 9y ago
Or use other statically compiled languages instead. Or at least use Java or O/S sandboxing features. At least in the web-facing parts of their apps. In any case, this requires some planning ahead, and a mindset different from "agile". Maybe Java 9's AOT compilation can help in the process, but even if it could produce stand-alone programs, I think the dynamisms in Java code (reflection, annotations, dynamic class loaders) will make this infeasible for most code bases.
wschroed 9y ago
He is saying they should practice process isolation. Example architecture: https://cr.yp.to/qmail/guarantee.html https://cr.yp.to/qmail/guarantee.html
- phamilton 9y ago
  He also suggests that even with process isolation in the application layer, the database is likely not going to be isolated and you'll be breached anyway. The qmail architecture would likely be very inefficient with 100M+ users.
bunderbunder 9y ago
I don't know Java well, but at least in .NET it's possible to set a flag that disable execution of dynamically emitted code. Obvs, you should do this on every box that accepts connections from the outside world. Obvs, it's no easier to get people to do this in practice than it is to get people to quit using string formatting to get parameters into their SQL queries.
- tomrod 9y ago
  Make it opt out/default behavior.
paulddraper 9y ago
Buffer overflow
mannykannot 9y ago
DEP and ASLR provide significant mitigation of the threat posed by this capability in statically-compiled languages, so it is definitely an issue that should be considered, along with others. Having said that, it is unlikely that there is any merely technical solution for the problem, which arises from the whole system being predicated on a falsehood - the assumed confidentiality of SSNs.
daxelrod 9y ago
Programs in C and C++ can still execute data as code with buffer overflows. They're not a panacea either.
- ithkuil 9y ago
  That's right, but the OP did mention how that issue is addressed in c/c++: > so you can't use straightforward NoExecute bits (provided by hardware and supported by OS loaders to disallow calling into dynamically allocated memory

skybrian 9y ago

Before getting too deep in to this, how do we know it had anything to do with injecting bytecode? It's not clear that's what the Struts bug was about.

deleted 9y ago
[deleted]

seedless_sensat 9y ago

Why is the top comment about the JVM? This has nothing to do with the article.

mindslight 9y ago

> I found the argument convincing that even naming the breach "identity theft" is beginning to push responsibility away from Equifax and make it seem a personal problem of those affected, or a general societal phenomenon. When in reality it's just Equifax's poor security practices. The thing being hidden isn't the surveillance bureau's poor security practices, but the banks who actually extend credit. Banks want to pretend that they can define identity as equivalent to a few bits of public information, and when they're defrauded blame innocent bystanders instead of their own broken abstraction.

curun1r 9y ago

There are two massive problems and neither of them have anything to do with executing attacker's code. First, for Equifax, their databases should be sufficiently isolated from front-end web servers. SQL gives you the ability to, in essence, ask the database any question the data can possibly answer. Instead, Equifax needs to do the work to enumerate all the questions they want the data to answer and put intermediate API services in place that answer only those questions. Public-facing web servers should only be allowed contact the intermediate API servers, and not the database. With data that has the value (to an attacker) that Equifax's database does, this is the minimum that needs to be done to offer reasonable security. Second, there's an identity problem. That identities can be stolen using largely facts about people (name, address and such and, yes, SSN) is a fundamental problem in how we identify people. They're using non-secrets in a way that assumes they are secret. A Keybase identity is much closer to the model that the industry needs to adopt. Chalking up the cause of this to flaws in some ancient Java web framework that's barely used anymore is just sweeping the true problems under the rug. The industry needs a fundamental overhaul to how they identify people and mandatory security compliance (hey...they foisted PCI-DSS on etailers and card processors, so they can't complain when something similar is foisted back on them) to keep our information safe.