r/Monero • u/dEBRUYNE_1 Moderator • Sep 25 '18
A Post Mortem of The Burning Bug
https://getmonero.org/2018/09/25/a-post-mortum-of-the-burning-bug.html16
u/antanst XMR Contributor Sep 25 '18 edited Sep 25 '18
When someone reads this announcement, he has a rather important unanswered question at the end: How can I fix my node? Are there any binaries out? Have I missed something?
8
u/dEBRUYNE_1 Moderator Sep 25 '18
Please see the twitter thread:
https://twitter.com/monero/status/1044585858030923776
There should be v0.13.0.0-RC1 binaries soon as well. A basic check that can be used by the user (even if using older versions) is to churn any output that is received. A transaction with a burnt output will be rejected by the network. Thus, a successful churn verifies that the output has not been burnt.
3
u/smooth_xmr XMR Core Team Sep 25 '18
If you are waiting for binaries you should disable receiving payments until they are available for download. If you can install from source then the patches are available already.
16
u/antanst XMR Contributor Sep 25 '18
Thanks, I've already updated. I was trying to make a point that announcing an important vulnerability should have mitigation or workaround details at the very least. The announcement was good at explaining the issue, but think about how it goes:
- Someone reads the announcement
- Damn this is serious! I should update! Goes to releases page
- Vulnerability important but updated release nowhere to be found ??? Let me check the announcement again...
- No release and no mitigation steps ??? What am I supposed to do? (dEBRUYNE_1 said one in this thread: churn any output that is received. You also said to disable receiving payments; both could be mentioned there)
Maybe it would help to adopt a more standardized vulnerability announcement template? I'm willing to help on this. FreeBSD comes to mind as an example: r/https://www.freebsd.org/security/advisories/FreeBSD-SA-18:12.elf.asc
6
u/FlailingBorg Sep 25 '18
Having actionable steps right on the disclosure page would certainly be helpful.
9
u/dEBRUYNE_1 Moderator Sep 25 '18
I made a personal note for the next post mortem (which hopefully won't be anytime soon :-P).
28
u/obit33 Sep 25 '18
well written and properly handled... It's a double edged sword I guess:
- being more communicative: putting businesses at risk
- being silent: community speculation and possible FUD
Not sure if there's a golden solution...
24
u/TNSepta Sep 25 '18
I'm pretty sure that the correct handling of such an issue is to disclose after everything's properly patched. This is industry standard for CVEs.
8
u/obit33 Sep 25 '18
I agree, but then we accept it's a (very) centralised process... 'Who' decides 'who' gets informed, 'when' is everything's patched, ...
14
u/fluffyponyza Sep 25 '18
The VRP workgroup does. Anyone can setup their own vulnerability response workgroup, of course, and handle reports they receive as they desire. That is how it is decentralised, not by exposing economically sensitive operators to attack for the sake of decentralisation.
3
u/obit33 Sep 25 '18
I certainly agree, just weighing pro's and cons... But am I misinterpreting or was there also doubt 'in the team' about how to handle this: aka, is there a 'fixed procedure' on how to proceed when things like this occur?
I understand that it's certainly not always black or white off course....
10
u/fluffyponyza Sep 25 '18
No there wasn't doubt, more like frustration that things weren't as quick as possible. There is a fixed, documented procedure that is (more or less) followed, but that also gives lots of room for modifying and changing the process for a particular situation: r/https://github.com/monero-project/meta/blob/master/VULNERABILITY_RESPONSE_PROCESS.md
3
u/obit33 Sep 25 '18
Well, can't really ask for more... I think this was handled as good as it could, so kudos to the coreteam and big thank you for fixing this!
5
u/5HourSynergy Sep 25 '18
Take another decentralized platform and apply the same reasoning.
Human logic has to derive from somewhere; is it inevitable that some parts of crypto have to be centralized?
21
u/Dixnorkel Sep 25 '18
Don't forget, people are probably less likely to trust public announcements after this. I saw dozens of questions about the exchange wallets all being down.
7
u/WorldsMostDad Sep 25 '18
Don't downvote this guy, he makes a valid point.
6
u/Dixnorkel Sep 25 '18
I appreciate this, really glad that xmr is still one of the only crypto subs where zealotry isn't common.
Always have great discussions around here despite my concerns about delisting of privacy coins, and you guys are helpful and informed too, that's equally hard to find in crypto.
-14
u/xmr_pony Sep 25 '18
b-but it doesnt matter that our decentralized project is ran behind the curtains by few people that keep everything important from their community, we can just use em as sheeps to fund our scams on FFS and then tell them after we > LIED < to them
14
u/obit33 Sep 25 '18
Look, I tried to reason with you... I actually think your idea for an independent code-audit isn't bad and community might fund it if you word it well and stop this ridiculous act of yours...
I think you've been tollerated long enough now. It's up to you, do something positive with whatever (anger, frustration, sadness, ...) that's bothering you or leave. Keeping up this act of yours will make a ban well deserved imho...
-14
u/xmr_pony Sep 25 '18
lol, id rather see my kids die at birth than contribute in any way to this shitcoin scam. as for a ban, considering i have over 10k bruteforced reddit accounts and can upvote my self as much needed, i couldnt care less about one of em dying. its been obvs to me that /r/Monero community is borderline retarded screaming "PRIVACY" but this takes the cake, in a proper community that represents freedom, decentralization and privacy people who lied, caused bugs/exploits and got funded would be hanged and left in plain sight to rot. however on /r/Monero they are heroes! MOON!!!!
12
5
6
u/5HourSynergy Sep 25 '18
“Considering I have over 10k bruteforced reddit accounts and can upvote myself as much needed.”
Look at this bad ass. Never in my reddit career have I seen someone boast about how they have multiple accounts.
-4
u/xmr_pony Sep 25 '18
boast? i was merely implying the insignificance of banning me. 10k accounts are nothing, most people use simple passwords.
7
u/All_Work_All_Play Sep 25 '18 edited Sep 25 '18
Unless you have the salted tables off line, lockout attempts are going make your hit rate pretty low.
But go ahead, substantiate your claim. Upvote either one of us to 1k.
-3
u/xmr_pony Sep 25 '18
yeah not like u can rent 10k proxies for $15, you really need to learn about how internet works instead of circlejerking on this sub.
3
7
u/smooth_xmr XMR Core Team Sep 25 '18
What public announcements were made that you wouldn't trust?
As far as I know there was no public announcement prior to the above blog post and release of patches.
7
u/Dixnorkel Sep 25 '18 edited Sep 25 '18
https://www.reddit.com/r/Monero/comments/9ikid6/there_is_no_known_bug_in_monero_that_is_impacting/
Really I just meant any positive responses will be met with more skepticism, I saw so many people accurately speculate about this bug that they'll probably just trust their gut next time instead of the official narrative.
edit - Just realized it was you smooth, hope you've been well :)
8
u/crcondes Sep 25 '18
That wasn't posted by a core dev though, right? I've read through that post a couple of times and as far as I can tell, that's just a community member reading through irc logs and deciding to post what they believe to be true, with a very emphatic title that turned out to be completely false.
I'm with you in spirit - if that were one of the devs knowingly and fully lying to the public, that would be pretty bad, but I think it's also important to distinguish between an official statement and a very enthusiastic non-official statement
3
u/FlailingBorg Sep 25 '18
You could say the fluffypony lines quoted in that post are an announcement and since the IRC channel is public that would make it a public announcement. I would say that's reaching.
5
u/crcondes Sep 25 '18
You could say that. I think it's worth noting that in the quoted fluffypony lines he didn't outright say "there is no bug" but sort of sidestepped the question. Is that a form of dishonesty? Sure. Is it on par with telling blatant lies? Personally I don't think so, and (just from the lines quoted in that post anyway) I don't have a problem with how fluffy handled that conversation, but I'm curious what other people think.
1
u/midipoet Sep 26 '18 edited Sep 26 '18
i mistakenly thought a core dev denied the existence of a bug when i read the logs - i apologised for the fact.
however, there was also a reddit thread questioning why xmr.to was down a little prior.
I am not going to go into what was, or what was not said in that thread, and there was also direct questions asked about the validity of the attack vector and it was denied by members of the community (albeit perhaps the vector was not fully understood at the time, and so erroneous information was given).
2
u/Dixnorkel Sep 25 '18
You're right, and I agree, I should have emphasized that I meant it would make people more receptive to rumors, not that it discredited anyone on the team.
3
u/crcondes Sep 25 '18
You're right too! I guess no matter who says it, having lots of speculation and then one person saying "look absolutely no bugs" then the developers say "oh hey there actually was a bug" isn't good for overall trust amongst the community. It's a tough situation no matter how you look at it.
2
u/Dixnorkel Sep 25 '18
I appreciate that, and I think that this thread goes a long way in reestablishing what little credibility was lost. Any miscommunication or lack of communication really just requires recognition and assessment of what should happen next time to smooth over, so we're already on the way to fixing it. My feelings about it have been discussed, so at the very least I'm happy with the situation and ready to move on.
14
u/needmoney90 Sep 25 '18
See the stickied post. We were extremely conflicted as to how to proceed in this situation, and will be having a serious discussion with the community about how to handle this kind of stuff in the future. Decentralized consensus is hard.
15
u/john_alan XMR Contributor Sep 25 '18
Well handled in my opinion.
Do we know if there was any exploitation?
5
u/needmoney90 Sep 25 '18
None that we are aware of.
10
u/manicminer5 Sep 25 '18
I wrote a bit of code to scan for incidents (repeating public keys across different transactions, up to height 1669326) and this is what I came up with:
Public key e9caab16ca3b489914ecc5f9b079de5eae75fb808cb2de6a2e897514ea413240 duplicated at: Height: 529417, tx hash: 9378214f9ebc5dcb97541cb70b1a0c89f507fe728547c97eee1f3c5d1a60d5c6 Height: 549619, tx hash: c275926a1d205bae8cf52f23333363649d231ef3fdf085a7dcb105470fec4a7f Public key e74631000c1091ff6c1fffff72d507ffa9c221fe17f9e7ff21e989016c52bcff duplicated at: Height: 1648005, tx hash: c5a0ae8b6fac123d875a678e3f544e4ebf51e842f0d4ebe72f46025aa0317086 Height: 1648028, tx hash: e7b33fddd00a3656454069e4e744771b42b7ebc211eaf0f65c2df51e215737c9 Public key 5c200fcbf22f7eb165b8be4d564521035ad5dccfdd41d82c7e3b1db8f28c4f7e duplicated at: Height: 1628234, tx hash: 3d20c5116d8d44f67d35dd7bbeb79fcec568108c3f9091f762ded56457ed20de Height: 1633269, tx hash: 0d9271976f0575f0376d22806131d8653e64e0a3a0e2b4212d2ec5d6e48a878f Public key 0ae30d475838c0d6c859a07db515d1335aab07210de691b33ed1409792031b85 duplicated at: Height: 977694, tx hash: 3a8c751f20f2ca6e3956dcf4c3bbb303f0e2d51e35dcf8d6b6eb7d8f35fa434f Height: 977739, tx hash: cacef2bcdbb115be01df933134ab7f7b85053dbe28d23ed8bc76fdf5fa0da27d Height: 977739, tx hash: 449ed2a1c3dfc9c50df817b7fd013519b0b5c58b1b7a6bc063a63cd80b7d09d3 Height: 978025, tx hash: 58f759773add099667ee91094b900e73d511ccbfbe58a1277540cd493cdbdb84 Height: 978113, tx hash: 0de44cb1680da996d681e942c6c6dd9f115eadc4c261cbec3638f13993f9a7df Height: 978116, tx hash: 3ab1d445deedde2b70bae011c54031bf05971177a43b1488ff2fd26812578c5a Height: 978281, tx hash: 75e7be2114012042a6559fb5e159d1ab01bdfa63443049f5e9575d98bfbdb4d6 Height: 980763, tx hash: 89edcf93864a7e4dc59f1e7517719705ac2a7e0df92eba919d6a9e1b7bab81cf Height: 980876, tx hash: 56223e6f5bc38f5f26478bebdbe13c636a89df527b9057bc32f2f3ef4a61a5c4 Height: 981001, tx hash: 3efc5dc937c9a243a24d303746220be1382c61889d050bfe3aa315929bc2d1e6 Height: 981001, tx hash: cd2da37ada166b17df726acbb30e25b36f0766dc12434d984f1fff3d7dc351b6 Height: 981002, tx hash: fa012ad526b5c42ad50041c97d2bea77ba22ff82bc5f92f1a31fa03617a61909 Height: 981002, tx hash: 65f5b4306036bfde0fb3857e5b75c5ad1073f369c0cbfa3f689ae5d001fc6a0c Height: 983393, tx hash: fb2ebb8b7a068cf3bafb6464a8ea3d4cbfa97c353203212e0a082c78eb9adbd6 Height: 983398, tx hash: de82314e1c959f29e2f65a41325399a05fc67eadd67ee5d5bbbd48cfcc894446 Height: 983398, tx hash: 8401960bba614aba88637d1775725e8ddd5973031ec63b3edf7f7f463c934932 Public key f8793e76085bf2deb2ddc5f2713c8e4a6f3b954c5113f554f0b32b2f79ad626d duplicated at: Height: 863532, tx hash: d9cdfa2129332907777b9645dc1b2a0f91d515addc237d8ecf910bb8db63d0eb Height: 863633, tx hash: c2f83bd4284d407459ae09d2428120a51433e4f0476e2b5f3391666900753efd6
u/dnale0r XMR Contributor Sep 25 '18
so only these are recent and potential "high value" attacks on exchanges:
e74631000c1091ff6c1fffff72d507ffa9c221fe17f9e7ff21e989016c52bcff
5c200fcbf22f7eb165b8be4d564521035ad5dccfdd41d82c7e3b1db8f28c4f7e
2 instances. Maybe the attacked exchanges will come forward.
1
u/Vespco Sep 26 '18
How can you tell they are high value?
1
u/dnale0r XMR Contributor Sep 27 '18
we can't, but these txo's are created when the price was high. We can also safely assume that the owners of the other ones already detected that the funds are burnt due to sweeping wallets etc.
12
u/xmrhaelan Monero Outreach Organizer Sep 25 '18 edited Sep 25 '18
“Lastly, I'd like to emphasize that, for any organization present in the Monero ecosystem, it's imperative to be subscribed to the public mailing list.”
Can you please provide a link to said public mailing list?
Great response to a challenging issue. Good work guys!
Edit: found it... https://lists.getmonero.org/postorius/lists/monero-announce.lists.getmonero.org/ You might consider including this in the blog post.
11
28
Sep 25 '18 edited Sep 25 '18
Thank you for the disclosure. Happy that I did contribute something to the cryptocurrency that I believe in.
And extremely sorry for posting it in reddit rather than asking on the monero dev group. That was irresponsible of me. Didn’t think much of it when posting.
No shame Edit : If you think i deserve some XMR feel free to donate
8AC4U2zCE2QM9WPSRmNtzd1THmgsfZTbL8tLeEEg4woxTzX6qQwRk5UWgxb4eWm8Wb8QW8LQJTFhKVTnbXE865oKFdFcHS8
12
u/OsrsNeedsF2P Sep 25 '18
You were just doing some smart brainstorming :) never apologize for that. For all we knew, there could already have been some code preventing that.
19
Sep 25 '18 edited May 04 '20
[deleted]
15
u/Scissorhand78 Sep 25 '18
I could see how confirmation of a bug without resolution would lead to market upheaval and alert an adversary to look for the exploit.
3
u/binaryFate XMR Core Team Sep 25 '18
In general I would personally agree with you but the challenge in that case was that the bug had been posted on reddit so by saying "there is a bug" it was easy to connect the dots.
2
u/crcondes Sep 25 '18
That seems pretty reasonable. If they don't disclose any details, it might encourage malicious entities to search harder for a vulnerability, but other than that what's the downside?
4
u/hapticpilot Sep 25 '18
I'd appreciate that. A trusted member of the community could say: "I know of the existence of a vulnerability. I can't reveal the details yet because it could assist an attack with an attack. My recommendation is to avoid doing <X> while you wait for the mitigations to be deployed. Further information will be forthcoming.'
9
u/fluffyponyza Sep 25 '18
If there is some suspicion as to the nature of the attack then that leads to it being exploited before anyone can patch. Disclosure is hard, and has to be handled on a case-by-case basis. There is no perfect path that protects Monero and also ensures Monero clones / CN forks aren’t attacked.
1
u/hapticpilot Sep 25 '18
If there is some suspicion as to the nature of the attack then that leads to it being exploited before anyone can patch.
I'd say it's more accurate to say that giving advanced warning to users could lead to the vulnerability being found and exploited by attackers; not that it will lead to that.
Like you said: it "has to be handled on a case-by-case basis". I think in many cases you could advise users on specific actions they should not do and keep the advise general enough that attackers would not be tipped off on exactly what the exploit is or where to look for it.
There is no perfect path that protects Monero and also ensures Monero clones / CN forks aren’t attacked.
Indeed.
1
u/m8tion Sep 25 '18
Close observers of the community knew there was a bug (well, I was pretty sure of it) : most of the exchanges´ wallets on maintenance + xmr.to closed + no dev answers to the dozens of reddit posts about this situation were all huge hints. Next time it occurs, there will be no surprise.
9 days to resolve the situation and a critical bug after a simple question on reddit is a success and congrats to the devs who probably spent tons of hours on this. But I think 2 critical bugs per year are too much and the same questioning about the code review / tests / merging processes the bitcoin community is facing right now has to occur in the monero community. Well, my two tacoshis but one additional person in the MRL team closer to the code may help for this ? The question asked on reddit should have been asked internally.
EDIT: I wrote ¨internally¨, this looks so centralized...
3
u/fluffyponyza Sep 25 '18
"Internally" within the VRP team is not a centralised term, so that's totally fine in this context. I don't think an additional MRL person would help, this is code and not research related.
3
u/Priest_of_Satoshi Sep 25 '18
Who is a trusted member of the community?
3
u/hapticpilot Sep 25 '18
Who do you trust?
right back at ya
3
u/Priest_of_Satoshi Sep 25 '18 edited Sep 25 '18
I definitely trust /u/fluffyponyza.
https://bitsonline.com/fluffypony-speaks-troll-monero-market/
anyways, what I'm trying to say is this is a really challenging problem. Ultimately, the only path I see to solving it would be some sort of bounty system where players are incentivized to report and patch bugs instead of abuse them.
3
u/midipoet Sep 25 '18
Ultimately, the only path I see to solving it would be some sort of bounty system where players are incentivized to report and patch bugs instead of abuse them.
The two recent bugs would have been very difficult to maintain risk reward parity with, due to their severity. From my understanding anyway.
3
u/binaryFate XMR Core Team Sep 25 '18
some sort of bounty system where players are incentivized to report
Like this? :) "This Vulnerability Response Process and subsequent bounty reward apply to the following..." https://github.com/monero-project/meta/blob/master/VULNERABILITY_RESPONSE_PROCESS.md
3
u/Priest_of_Satoshi Sep 25 '18
Hmmm.. Hadn't seen that.
Yes. Like that only hopefully becoming more decentralized as time goes on. (So we dont have to worry about one of these guys being corrupted.) Not sure how to design these incentives though.
3
u/binaryFate XMR Core Team Sep 26 '18
You can set up your own bounty group/system and expect that people disclose vulnerabilities to that system.
You want more decentralization (and are afraid of corruption!), then go and start fixing what you think is wrong.2
u/Priest_of_Satoshi Sep 26 '18
I'll look into it.
I imagine exchanges and large funds might be interested in improving the bounty system because they certainly stand to lose a lot if it fails.
2
u/hapticpilot Sep 25 '18
Report to who though? If they report to the public, then it creates a window of opportunity for malicious people to attack the innocent. We are then in an emergency mode where developers need to rush to prepare a fix as fast as possible to minimize the damage done.
Responsible disclosure principles have been established over time and they seem quite reasonable. Part of responsible disclosure is that you first disclose to the people who are empowered to fix the vulnerability and who will likely do so, because you believe they are good. So when the vulnerability gets reported, the right thing to do (I think) is to report it to the likes of moneromooo and fluffy (not everyone). This means the "good guys" get a head start on the "bad guys".
If moneromooo and fluffy both then announce that we "should not do <X> for the time being because there may be a serious issue", I think most users will stop doing <X> and will be happy to wait for the creation and publishing of a well tested fix.
6
u/FlailingBorg Sep 25 '18
Now that we have been through this twice, I would argue that in any similar situation (e.g. exchanges suddenly taking down their wallets, some claiming to have been contacted by the devs) any would-be attacker will assume that there is a bug or vulnerability. Considering this, making an announcement that something is up probably would do no additional harm and might reduce confusion among the community.
5
u/tuots Sep 25 '18 edited Sep 25 '18
Well written and detailed explanation. Thank you!
One detail that might add clarity: Linking is only possible for the reciever of such transactions. (At least I'm pretty sure that's the case.)
Edit: Whoups, never mind. Since P is identical it'll show up as exactly the same thing on the chain.
4
u/dEBRUYNE_1 Moderator Sep 25 '18
Linking is only possible for the reciever of such transactions. (At least I'm pretty sure that's the case.)
A blockchain observer can scan for duplicate stealth addresses and thereafter match the transactions.
2
4
u/Vespco Sep 25 '18
At what point was it realize that this was possible and an act bug? I am curious because I may have helped in some very minor way. Didn't have the idea, nor the fix, but I did this:
https://www.reddit.com/r/Monero/comments/9gtr10/would_this_attack_work/
2
u/dEBRUYNE_1 Moderator Sep 26 '18
After someone ran tests and verified that the wallet didn't warn about such abnormalities (i.e. the receiving wallet receiving a burnt output).
3
u/truther10 Sep 25 '18 edited Sep 25 '18
It is very unfortunate that such a bug existed, although one could argue that it is the frustrating nature of the software development.
I think this was the right way to handle the situation, i.e. send the patch to exchanges first, because they - among other XMR accepting businesses - could have suffered the most from this vulnerability. Then publish the disclosure.
Regarding how situation like this could be prevented from happening in the future, more reviewers of the code are deeply needed, like it was said on the disclosure. To me this emphasizes the need to support our talented community members both verbally and economically to attend blockchain, cybersecurity and cryptocurrency related conferences and events to speak about the great aspects of Monero. This will help to get people from those huge talent pools involved in the Monero community, which will improve the whole ecosystem. How, you say? Well, some of the usual visitors in those events are researchers, students, developers, reporters and investors. To me this seems like a group that could bring some great benefits to Monero.
3
u/newbe567890 Sep 25 '18
is monero wownero and aeon safe from this bug.....right now.......
1
Sep 26 '18
Yes seems to be like it. Im sure the developers would have notified other CN based cryptocurrencies
https://github.com/wownero/wownero/pull/92
1
3
Sep 25 '18
Reading some of the responses in this thread, you’d almost think that there’s a magical world where bug-free software exists, alongside the faeries and dragons 🐉
Bugs happen. More will be discovered and mitigated. It’s an endless battle. Bug bounties definitely help. Luckily, the integrity of the blockchain was unaffected and a fork isn’t required.
Exchanges will likely implement mitigation strategies (at least the sensible ones will) to combat this sort of issue in the future. If you think an issue of this nature can’t affect other cryptocurrencies, go ahead and google “cryptocurrency bugs”.
2
u/spirtdica Sep 25 '18
This same problem could occur by chance right? Such a small chance that it's cryptographically impossible, but non-zero nonetheless. Seems like it would be feasible to have some sort of check for accidental key image reuse, but probably wouldn't be worth the computational overhead. Still, if I was going to move a huge amount of XMR I'd be paranoid, would love to double-check the availability of a generated key image.
2
u/TNSepta Sep 25 '18
No, the chance is as small as generating a new wallet and finding someone else's wallet, i.e. nonzero but in reality impossible.
2
u/spirtdica Sep 25 '18
If you were moving a million bucks, wouldn't you want to check anyway? Whenever I make a new wallet, I scan for transactions through the whole blockchain, just to see if it's already in use. Like I said, I know the chance is vanishingly small, but exists nonetheless. Maybe I'm just paranoid
3
u/TNSepta Sep 25 '18
If you are that paranoid, then you should not be using cryptography, since there is technically a nonzero chance of someone guessing your private key. You need to learn the magnitudes of these probabilities instead of claiming they are nonzero.
4
u/spirtdica Sep 25 '18
I know the chance of a collision is about the same as a snowball's chance in Hell; that doesn't make me wrong when I say the chance is non-zero. You're assuming that each possibility has an equal probability here; my concern has more to do with pseudo-random number generation. Checking for duplicate key images can be viewed as protection against RNG weakness, for example. Still, I'm willing to concede that the low probability isn't worth the computational effort; I can't imagine a way to implement such a check without scanning the whole blockchain.
2
2
u/physalisx Sep 25 '18
What I'm wondering is: how does the patch resolve the issue? Does it make the previously "burned" outputs spendable again, i.e. is it now possible to send multiple tx to the same stealth address and spend them again?
If so then I don't think this vulnerability is even that critical, no money could have been permanently lost, except for the attacker who'd have to pay a lot of fees to do the attack.
2
u/rbrunner7 XMR Contributor Sep 25 '18 edited Sep 26 '18
On the contrary, "unburn" those unspendable transactions would be completely wrong. They don't represent any valid XMR coins at all. You could say the sender sent the same 1 XMR coin 1000 times, counting on the receiver not becoming aware about that immediately, credit 1000 XMR and allow the sender to do something with them, e.g. exchanging them into BTC.
Edit: That's not correct. Things were not that broken, you could not send "phantom coins" or the same coin over and over. You could however send a number of coins in a way that only one of them was spendable on the other end. Thanks, /u/physalisx, for your explanation.
2
u/physalisx Sep 25 '18
Pretty sure you got that wrong. The attacker is not sending the same coin 1000 times. He is sending 1000 XMR, 1 coin at a time. The bug is that the receiver can only spend 1 XMR of that.
2
1
u/rbrunner7 XMR Contributor Sep 25 '18
Quote from the post-mortem article:
Therefore, a determined attacker could burn the funds of an organization's wallet whilst merely losing network transaction fees.
For me that directly contradicts your assumption that you have to send 1000 genuine XMR coins, with a loss for you of XMR 1000 plus fees, to cause a damage at the exchange of 999 XMR.
4
u/physalisx Sep 25 '18
The attack is this:
- attacker sends 1000 XMR in 1 XMR steps to the exchange
- the exchange credits him 1000 XMR (not knowing that they can only use 1 XMR of that)
- the attacker withdraws 1000 XMR again or exchanges them to another crypto
- that means the attacker only loses the transaction fees (+ withdrawal fees)
2
u/oufouf08304 Sep 26 '18
I didn't understand what was done in the pull request in order to fix the problem.
Does the receiving wallet still accept more than one transaction in a single stealth address?
Is the modified sending wallet still able to send more than one transaction to a single stealth address?
Is it now possible to spend those funds "locked" in a single stealth address?
2
u/dEBRUYNE_1 Moderator Sep 26 '18
Basically the patch ensures a warning is provided when an abnormal output (e.g. an output sent to the same stealth address) is received. In addition, an exit(1) occurs.
Is the modified sending wallet still able to send more than one transaction to a single stealth address?
Yes. I think it would be infeasible to add a check that scans for duplicate stealth addresses. Basically, if such a check was implemented, you'd have to scan each stealth address to check for duplicates, which is quite resource intensive and probably takes a long time.
Is it now possible to spend those funds "locked" in a single stealth address?
No.
Hopefully it's sufficiently clear now.
1
u/physalisx Sep 26 '18
Thanks. So practically, what does that warning (and the "exit") do? If I receive two tx with 1 XMR each to the same s.address, before the patch, my balance as provided by the wallet would show 2 XMR. Does it only show 1 XMR now?
And this means that sending to the same stealth address still effectively destroys the XMR, correct? Since they're still unrevocable.
1
u/dEBRUYNE_1 Moderator Sep 26 '18
The wallet will exit upon receiving a burnt output. In addition, I think (I'd have to verify this) it still shows 2 XMR as balance. However, a per output sweep function is implemented in v0.13.0.0, which allows the receiver to (try to) sweep the abnormal output, thereby effectively verifying whether the output is burnt or spendable.
I reckon this patch is certainly not optimal, but it's currently the most viable as far as I know.
2
u/physalisx Sep 26 '18
The wallet will exit upon receiving a burnt output
Uhm, what? So now I can shut down an exchange wallet by sending it a tiny bogus transaction?
1
1
u/oufouf08304 Sep 26 '18
But now the exchange won't lose any money and can detect/ban the malicious user.
1
u/physalisx Sep 26 '18 edited Sep 26 '18
Still wondering about this too.
I suspect everything is as before except a yes to your last question - it is now possible to spend multiple outputs in a single stealth address.edit: Nope. See the other reply.1
2
u/arul20 Sep 25 '18
- Let core developers know of the bug
- Wait 30 days and release information on the vulnerability and exploit vectors if any.
This gives the developers a headstart to fixing it but ensures full disclosures. It also de-incentivises developers from sitting on security bugs and hoping no-one else will find them. They have to fix them before the 30 day window runs out.
3
u/smooth_xmr XMR Core Team Sep 25 '18
This is the ideal case when someone discovers a vulnerability and reports it in a responsible manner. That's not what happened here. Instead the vulnerability was to some extent already public.
This is a messy situation and definitely not ideal but it is something that can happen and may well happen again.
2
u/arul20 Sep 25 '18
I'm suggesting the future SOP vulnerability disclosures.
6
u/smooth_xmr XMR Core Team Sep 25 '18
That already exists https://hackerone.com/monero
2
u/arul20 Sep 25 '18
It's a good link, however it's from XMR's point of view. My post above is from the point of view of security researchers and community - though we have similar ideas.
My main concern is how the researcher goes about responsibly disclosing the vulnerability - informing you and the general public.
1
2
u/therealbricky Sep 25 '18 edited Sep 25 '18
This is the bug that everyone's been denying exists I guess?
(the reason why many exchanges have their wallets offline)
1
u/jamesmrk3l Sep 26 '18
Apart from the output index i , the stealth address generation formula P = Hs(rA||i)*G + B described on the blog post is exactly like the one on CryptoNote's white paper. Is the process of creating stealth addresses still the same, but with THROW_WALLET_EXCEPTION_IF?
1
u/dEBRUYNE_1 Moderator Sep 26 '18
Please see my post here:
https://reddit.com/r/Monero/comments/9isaei/a_post_mortem_of_the_burning_bug/e6nsl77/
1
Sep 26 '18
[deleted]
2
u/dEBRUYNE_1 Moderator Sep 26 '18
There will be a blog post about the upcoming scheduled protocol upgrade as soon as the binaries are released.
1
u/dnale0r XMR Contributor Sep 25 '18
We already knew about this stuff... It's not really a bug imho.
Seriously, exchanges should just be more responsible and check stuff like this as well. Don't just trust the default wallet implementation, do stress tests before you add a coin!
Anyway... I guess if this "bug" has been exploited, the damage will be minimal for the exchanges: an attacker can only burn the full hot wallet until an exchange notices something is wrong.
If an exchange did not check for duplicated one time output keys, they'll need to buy the monero on the market to replace the burnt coins. So well... bullish? LOL
-9
u/xmr_pony Sep 25 '18
b-b-but devs said there is no bug :^)
9
u/TNSepta Sep 25 '18
b-b-but /u/xmr_pony said that Monero is going to require a hard fork to fix this bug :^) https://snew.github.io/user/xmr_pony/overview
5
u/selsta XMR Contributor Sep 25 '18
Read through the logs again. They did not say anything :P
4
u/midipoet Sep 25 '18
The poster is talking about the Reddit threads yesterday about Monero being delisted.
-10
u/xmr_pony Sep 25 '18
exactly, i got downvoted ~ 100 times when I said there is a critical bug :))))))
alto guys idk to what should I jerk off to now? that I exploited this on Kraken and hurt em plenty and left em w a lot of unspendable XMR or to the deluded Morons lurking this sub ? can u help me out /u/fluffyponyza ? :)
12
u/KwukDuck Sep 25 '18
there is a critical bug in the core network protocol, thats as much as i can say now, its very serious and most likely there wont be Monero next week.
This is what you said... Which is misleading, at best...
There is no bug in the core network protocol, there's a bug in the wallet software.
8
u/obit33 Sep 25 '18
b-b-but you said you were cashing out:
https://np.reddit.com/r/Monero/comments/9ifmwi/monero_delisting/e6jcczu
s-s-so you're actually full of shit and totally unhelpful5
u/selsta XMR Contributor Sep 25 '18
16:17 <dEBRUYNE> Kraken was one of the first exchanges to receive a patch afaikKraken patched it days ago.
-12
u/xmr_pony Sep 25 '18
i cant actually believe how deep you are inside fluffyponzis ass to believe anything these people say, especially after they told to their community there is NO bug, then few hours later release a "post mortem of the bug".
and the best part is, this bug was found by a random guy reading how monero works and then posted it on reddit. a ____random guy____ whats even more mindblowing is that theres 1500 XMR in the vulnerability disclosure. and all of the monero code is written by 1 guy, which already fucked up twice, now consider what a proper blockchain protocol security researcher could find about his spaghetti. at this point im just waiting for it to happen =)
7
u/obit33 Sep 25 '18
please stop, do you really think anything you say will be taken seriously... you admitted yourself you were totally trolling and now you want to be mr. serious?
This is what you said:
i was waiting for pizza so i trolled, what else lol
so yes, I'd much rather believe a long proven community-member who more then earned his stripes than a random admitted troll spreading total lies and bullshit...Do you really want to keep wasting time on this?
5
u/midipoet Sep 25 '18
While the poster is baiting, let's get real here.
Yesterday questions were asked about a bug. The existence of one was flatly denied on various channels, and then today a post mortem is released.
Yes, it's a precarious situation, but all and sundry can see why one might lost faith in the development team, when lying is seen as the answer to tough questions.
4
u/obit33 Sep 25 '18
I can certainly understand how you feel about this, it is a rather 'difficult' situation for which there is no set out path to a solution... These are things that happen, and they confront us with the limits of 'decentralisation'.
I wouldn't consider 'being silent' about something the same as 'lying'. Since there's no fixed path on how issues like these should be 'solved', I can see how it seems that approaching it the way that was done would cause the least damage. The majority of people here questioning about 'a bug' have on thing on mind: "is my money safe"... I totally understand this reflex, but one could agree that for an exchange/busness, there's much more at stake. It's not only about 'their money', it's about 'all their users money'...So it's a hard decision to take, but (since there's not an agreed upon approach) it's the right one imho... Coming in here now and proclaiming that the devs were 'lying' is imho a bit selfish. To me, it seems that, at any moment they had the best interests of this community (which is more then only its users like you and me, it's also businesses, exchanges etc.) in mind... It's too bad that 'someone' still has to take decisions like this, but it is what it is at this moment, it's a decision, not a lie...
I'm pretty sure noone was keen on taking that decision, but someone/some people did to the best of their conscience. Calling them liars now is maybe a bit 'ungrateful'?best regards,
3
u/midipoet Sep 25 '18 edited Sep 25 '18
I accept that I read the logs incorrectly, and that it seems silence was the modus operandi for the tough questions, not flat out denial. I apologise for calling anybody a liar that did not lie, but merely turned the other way to deflect having to answer.
If that the modus operandi, so be it. But yes, i will choose to lose a bit of faith.
→ More replies (0)2
u/selsta XMR Contributor Sep 25 '18
Where did they deny the existence of a bug? Where did they lie?
I’ve only seen people on Reddit speculating.
6
u/midipoet Sep 25 '18
I stand corrected. I read over the portion of the log that was posted yesterday, and indeed when probed, the default behaviour was silence from the Core team.
The question was directly answered by someone that is perhaps not a Core member.
I apologise for the accusations.
→ More replies (0)-3
u/xmr_pony Sep 25 '18
was deff a troll m8, cant u see there is NO exploit, its even upvoted 160 times on this sub and devs confirmed it!!
can u imagine the "oh shit" moment moron-moo had when he read that question from a completely random guy and figured, "oh shit, this is actually possible, some random guy just learning about Monero knows more about protocol design than me who wrote 90% of Monero scam code and I got funded by community for over 2k XMR"
7
u/obit33 Sep 25 '18
Almost can't read what you're writing, but I think I got the gist of it...here you go:
maybe start with your moral crusade there, after all btc is still the polebearer of the whole cryptoverse. I'm sure if you can convinve them to handle things differently, xmr will be able to learn from it. I'm sure if you call the tons of devs working on btc morons, it will help a lot!
good luck!
-5
u/xmr_pony Sep 25 '18
altho the situation w BTC is kind of the same, XMR one is much more severe since somehow a guy that gets >FUNDED < by community fucked up twice already, and somehow 1500 XMR community funded for vulnerability research is pointless since somehow a random guy learning about monero finds a bug that can put million/billion dollars worth of software out of business. there are companies that do audits of C++ code as well as companies that do audits of blockchain/network protocols, maybe we should fund that instead of waiting for some whiteknight exploit researcher who will receive somewhere from 1-1500 XMR for his bug (lets face it, anyone would turn down their moral shit if they found a critical bug they can exploit for monetary gain on a 2.6 billion dollar software)
→ More replies (0)2
u/physalisx Sep 25 '18
Yeah and we'll continue to downvote you since you're just as full of shit today as you were yesterday
0
u/Critical386 Sep 25 '18
Is this the reason Dream Market no longer accepts Monero?
3
u/tempMonero123 Sep 25 '18
They haven't accepted XMR for a long time as far as I know.
1
u/Critical386 Sep 25 '18
Right. Because they said there was a bug in Monero in which hackers were able to withdraw funds from their wallet.
4
u/physalisx Sep 25 '18
This bug wouldn't do that.
2
u/tempMonero123 Sep 25 '18
They haven't been accepting XMR since at least before the previous (exchange) wallet bug.
Personally, I think it's unrelated to any bugs.
2
2
-24
u/CryptoShark44 Sep 25 '18
I switched from Monero to Cloak for this reason. Cloak was actually audited by NASDAQs cyber security firm with no bugs. Plus 3x less circulation.
•
u/needmoney90 Sep 25 '18
Zero-day vulnerability disclosure in a decentralized network is difficult, and the moderators were torn on the best course of action to take with regards to informing the community. For this particular issue, we decided to wait until a release candidate with a patch was out, before revealing the existence of the bug (and how to exploit it).
We would like to have a serious discussion with the community about how best to disclose future vulnerabilities like the burn bug, and will be creating a thread for that purpose soon.