pull down to refresh
577 sats \ 3 replies \ @dhruv OP 4 Apr \ parent \ on: I'm Dhruv Bansal, co-founder of Unchained, AMA! AMA
Great question, thanks for engaging me on these ideas -- I think the bitcoin & computer security connection is really interesting and I wish more people talked about it!
To your first question -- you're right, vulns today do lead to significant financial loss. But I think vulns on a bitcoin-powered Internet would lead to even larger and more immediate losses and I believe the difference is large enough to be a distinction.
I'm a bit confused by this point "If we wanted to include Lightning transactions via every single request, sure - everyone would have to follow best practices and completely isolate and lock down that specific service. But that would only mitigate a single kind of vulnerability, and does not guarantee ethical or competent developer behavior throughout the rest of the web service."
^ What do you mean by "that specific service"? In the bitcoin-powered Internet world, any software that can make a network request from your device is software that can be used to steal money from you, since you're directly paying for network requests -- perhaps directly to the source host you're pulling the data from! So if a vuln in my software lets attackers make 1x1 pixel image request to attacker-controlled servers, that's basically a leak of sats my users will suffer. And they'll quickly see it, because it will be exploited quickly, and I'll come to know about it quickly, and I'll have to fix it -- or they'll stop using my software!
RE: the dissolution of the market for zero days -- I'm not making the claim that there will be no bugs on the bitcoin-powered Internet, just that there will be no zero days! Bugs can and will still exist and manifest, but they'll either be unknown to everyone or known to everyone -- the intermediate state of "known to attackers but not known to defenders" (a zero day!) will not exist because as soon as an attacker knows about a bug, if it can lead to the stealing of sats (via, say, the above 1x1 pixel image request attack) then it will be used to attack. It will never be sat on for weeks or months while it gets sold to another attacker in a zero-day market on the dark web. This is not true today -- a vuln in (e.g.) MS Word or some Siemens industrial control software found by some warez blackhat doesn't immediately turn into money, it has to be weaponized somehow first. If web requests cost sats, then it's far easier to turn vulns into money, and therefore selling them on zero day markets doesn't make economic sense.
To your second question -- I totally agree, the current stack is actually very robust after years of engineering on it. If we move to a new stack, that puts data within payments (I like the way you phrased that!) then we will have a boatload of new vulns that we create. You're absolutely right about this. Yet...so what? If the first part of my thesis is true, then these vulns will be quickly exploited because they'll be able to be used to steal sats. So they'll get noticed quickly and can be fixed quickly -- they won't sit as zero days for untold periods of time :)
Thanks for taking the time to read and answer my question!
So, I was thinking from the perspective of an attacker being able to leverage a vulnerability that would steal from the app as opposed to other users.
It seems like if I can isolate my application’s payment validation service (similar to the way SSRF is typically mitigated), other vulnerabilities within the application couldn’t be leveraged to access that service and steal from me.
But I hadn’t thought as much about attackers leveraging victim accounts…
But that leads me to the infeasibility of this whole thing in the first place.
It sounds like you’re talking about classes of vulnerabilities that leverage the fact that a browser is happy to automatically make whatever HTTP request the app tells it to. (Fwiw, that doesn’t include all critical severity/zero day vulnerabilities, but that’s a different tangent).
That seems to be based on the idea that LightningInternet browsers will similarly be happy to automatically send payment(request_data).
If that were the case, it’d be INCREDIBLY difficult to convince anyone to join LightningInternet, IMO. I wouldn’t visit ANY website if I had no control over how many requests (payments) are being automatically sent from my browser, no matter how trusted it is. If a single lapse in ethics or security competence can result in a lightning wallet being DRAINED, I’d stick to HTTP apps.
We’d have to build an entirely new internet that functions completely differently that would have an incredibly high security barrier to entry even without the new classes of vulnerabilities that will inevitably emerge.
To me, seems like we can accomplish a lot of the same incentives by building on established security and protocols, and ease into the new unknown a lot more smoothly by simply putting lightning payments into HTTP requests as frequently or infrequently as contextually makes sense.
reply
You're right to frame bitcoin-powered Internet as creating a huge, new space of vulnerabilities. If lightning browsers uncritically call
payment(request_data) then bad stuff will happen. People would have to develop rules to limit carefully what kinds of data they're willing to send and receive. Subversions of those rules, or the systems which enforce those rules, would immediately lead to costly and therefore quickly noticed attacks.Bugs which caused such subversions would not be zero days because they'd be exploited in the wild by their discoverer immediately upon discovery, not hoarded and privately sold in a darkweb market. After all, someone else could find that bug and start profiting from it, exposing it for all to see and squash. The economic incentive (of a blackhat) is to exploit a networking bug immediately before someone else does. This gets bugs fixed faster.
"Data in payments", to use your evocative framing, makes networking more secure by changing the economic incentives of attackers to shorten the lifecycle of bugs. I think this kind of pattern recurs in other areas such as distributed databases. Think of key-value sets and gets in some giant cloud database that is actually just a market. The same zero-day killing behavior will occur there, too. This is how I see a bitcoin-powered Internet emerging over time :)
reply
Interesting perspective. Thanks for sharing! I see what you’re saying a little more about vulnerabilities being exploited immediately…
What you’re proposing reminds me a bit of the scene at the end of Dark KnIght Rises where Bruce Wayne can only make the leap without the rope… More lightheartedly, I call this the Claw of Shame fallacy 😆
In other words, it sounds like you’re saying people will choose lightning internet because it has better security, and it has better security because if it doesn’t, the worst case scenario will happen… and I think I’m either missing some reasoning or missing the technical explanation to justify it, because I’m not sure why people would voluntarily opt in to that in the long run, let alone be a guinea pig…
So I remain curious to see what kinds of solutions people are proposing and building, because I’m all for better security!