"A bug in the wallet software allowed a determined attacker to cause significant damage to organizations present in the Monero ecosystem with minimal cost. Fortunately, the bug did not affect the protocol and thus the coin supply was not affected."
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?
Hopefully it's sufficiently clear now.
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.
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.
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.
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?
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.
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.
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.
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.
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)
Yes seems to be like it. Im sure the developers would have notified other CN based cryptocurrencies
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”.
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.
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
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.
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.
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.
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.
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*.
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.
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:
1. Someone reads the announcement
2. Damn this is serious! I should update! Goes to releases page
3. Vulnerability important but updated release nowhere to be found ??? Let me check the announcement again...
4. 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](https://www.freebsd.org/security/advisories/FreeBSD-SA-18:12.elf.asc)
Please see the twitter thread:
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.
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.'
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.
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...
> 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.
I definitely trust /u/fluffyponyza.
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.
> 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..."
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.
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.
> 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.
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.
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.
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 ? :)
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 =)
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?
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.
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.
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'?
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.
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"
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!
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)
>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.
b-b-but you said you were cashing out:
s-s-so you're actually full of shit and totally unhelpful
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 :)
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
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.
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.
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.
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).
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.
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
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...
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!!!!
“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.
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.
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....
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
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.
so only these are recent and potential "high value" attacks on exchanges:
2 instances. Maybe the attacked exchanges will come forward.
>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.
Quite a novel attack originally reported on Reddit.
Basically, it was possible to use a bug in the wallet software to send multiple outputs to the same stealth wallet, potentially allowing an attacker to cheaply burn a large amount of someone else's tokens, on account of the wallet simplying ignoring the issue.
This has now been fixed. Great work from the Monero team.
Can someone eli5? I couldn’t work out whether this is an attack on exchanges (modifying the client to reuse a key in a way that the exchange doesn’t check for) or something else.
The repeated use of “organization” made me initially think that this was an attack on a “foundation” (tor, eff, Mozilla, etc that kind of thing), but by the end I felt that it was meaning organization==exchange? If so I assume it would be an attack on exchanges prematurely believing a transaction succeeded? But seriously I’m curious what the actual correct interpretation is :)