Nxt source code flaw reports

[bidji29]

I think the goal of the 64-bits adresses is exactly to be "unsafe".


SO they can be bruteforced in the future with proper hardware. So all the DarkNxt are virtually minable and are not lost forever.


If you have a Nxt account and want to be safe forever, just do a transaction. It's simple

[etlase3]

The 64bit issue you are talking about is real but trivial to fix, hard to exploit and easy to protect yourself against.

It is also obscure. It is not obvious that not having a public key associated with an account reduces its security by 64 bits.

It is easy to protect yourself against it because as soon as you do a transaction, the public key is going to be associated and your account will be safe.

It also associates a signature with the public key, which opens up theoretical attacks. DSA/ECDSA and its variants are based on much weaker assumptions than hash algorithms.

Now, you'll probably try to say that someone did crack a 64bit key previously and you are right. However, it took them over 4 years...

With pentium 3 processors starting in 1998.

Commodity hardware is able to generate ~250k accounts per minute right now.
2^63 / 250 000 = 36893488147419 min = 614891469124 hours = 25620477880 days = 70193090.082 years

I'm using 2^63 instead of 2^64 because of the "Birthday Problem"

No doubt this will be fixed in 70 million years...

This is not an apt description of the risk.

[ricot]

2 small things in the Peer class:
- in addPeer you check whether address equals some strings that you consider to be localhost, but you don't catch all of them because of the new funny shorthand versions of ipv6 (e.g. ::1) or the even more funny ipv6/ipv4/mixups (e.g. 0:0:0:0:0:0:127.0.0.1). Why don't you convert it into a proper InetAddress and then use functions like isLoopbackAddress()? I haven't yet found anything I could exploit when your client is talking to itself, but such things often cause deadlocks.
- another one in addPeer: for most of the method, you accept announcedAddress to be something wrong and resort to address in that case. However, when you actually create the Peer object, you create it only with the announcedAddress, so you can end up with an Entry in your Peer Map that has a normal looking key (a working address) but the Peer actually doesn't contain any address at all.

On a different note: I can't find any code that divides an account's balance between peers that announced the same account in their hallmark...
It only computes the total weight of all peers and then divides accordingly. So if you have 300 nodes backed by the same 1M NXT account and one backed by 100M, you'll have a totalWeight of 400M and one of the 300 nodes will get chosen with a much higher probability than the one big node.

Thx, peer communication needs a lot of changes, one day I'll fix them.

This code divides weight - https://bitbucket.org/JeanLucPicard/nxt-public/src/4073c21098076d3469b3f74d49e73ffabe3a2001/Nxt.java?at=master#cl-2483

No, that code divides by total reported weight, and in my case that was 400M, so adjusted weight for each of the 300 servers would be 1M/400M and not 1M/300/101M, what it should be.

Anyway, my 0.5.1 just had the usual negative blocks crash and tried to rescan everything... the gui didn't get much of it, so i had to refresh the tab, and now there are still a lot of unconfirmed transactions outstanding (which are actually included in the blocks already). i'll investigate why that is the case...

[Come-from-Beyond]

i'll investigate why that is the case...

Don't waste time on that. Unconfirmed transactions list is not cleaned.

[ricot]

i'll investigate why that is the case...

Don't waste time on that. Unconfirmed transactions list is not cleaned.

I know, already found that.

Also, can you synchronize the gui updates so the gui doesn't choke on the issue?

[Come-from-Beyond]

i'll investigate why that is the case...

Don't waste time on that. Unconfirmed transactions list is not cleaned.

I know, already found that.

Also, can you synchronize the gui updates so the gui doesn't choke on the issue?

That's not very easy...

[ricot]

i'll investigate why that is the case...

Don't waste time on that. Unconfirmed transactions list is not cleaned.

I know, already found that.

Also, can you synchronize the gui updates so the gui doesn't choke on the issue?

That's not very easy...

synchronize blocksAndTransactions {} around the requests that get blocks and transactions?

btw: the not deleted unconfirmed transactions also explain the incorrect block created problem since the client assumes that unconfirmed means unconfirmed and includes them into the block

[edit]
damn, i'm always so behind on everything... i mean, it's been out for minutes now, MINUTES... i must be faster next time

[FrictionlessCoin]

Anyway, my 0.5.1 just had the usual negative blocks crash and tried to rescan everything...

Not sure if you already know... but 0.5.2 is out!  


https://bitcointalk.org/index.php?topic=345619.msg4371531#msg4371531

http://localhost:7874/update.html

Can someone send me the decompiled 0.5.2 sources!   

Thanks in advance!

[ricot]

Anyway, my 0.5.1 just had the usual negative blocks crash and tried to rescan everything...

Not sure if you already know... but 0.5.2 is out!  


https://bitcointalk.org/index.php?topic=345619.msg4371531#msg4371531

http://localhost:7874/update.html

Can someone send me the decompiled 0.5.2 sources!   

Thanks in advance!

Let me google that for you: https://www.google.com/search?q=java+decompiler

First non-ad hit, just open the class file, look at the stuff

[bitcoinpaul]

To fix this weakness forever, a simple no money, no fee transaction could be executed. Whenever you open a wallet, if the NXT client notices that your account on the chain doesn't have a public key associated with, it could issue a 0nxt/0fee transaction that is meant to record the key.

So every new account which gets opened just for a second would get 'loaded' into the blockchain. then, someone would open thousands of thousands of accounts to bloat the blockchain just for fun. i don't like.

wrong?

[FrictionlessCoin]

To fix this weakness forever, a simple no money, no fee transaction could be executed. Whenever you open a wallet, if the NXT client notices that your account on the chain doesn't have a public key associated with, it could issue a 0nxt/0fee transaction that is meant to record the key.

So every new account which gets opened just for a second would get 'loaded' into the blockchain. then, someone would open thousands of thousands of accounts to bloat the blockchain just for fun. i don't like.

wrong?

I have no idea why this implementation did not start with Bitcoin ideas and improved on them.

This re-invent the wheel from scratch really isn't a good idea.

All one had to do was replace Bitcoin's proof of work with NXT proof of stake.  But no,  it was more like, let's building everything from the ground up.

[ricot]

Ok, so 0.5.2 doesn't fix the exploit yet.
It does re-scan the block-chain, but something in there seems to be causing an exception and ...Done is never reached. (I can see in the logs that there was a second re-scanning started).

[bitcoinpaul]

blablabla

oh, not you again...

[Jean-Luc]

Ok, so 0.5.2 doesn't fix the exploit yet.
It does re-scan the block-chain, but something in there seems to be causing an exception and ...Done is never reached. (I can see in the logs that there was a second re-scanning started).

Fixed, now testing it.

[Jaguar0625]

Hey gang,

Any thoughts on this?  https://nextcoin.org/index.php/topic,2418.0.html

When a POST is done with "processBlock", there is no sanity check on "payloadLength". This means, an attacker could use this issue to DoS a node by keeping its heap exhausted all the time. This would trigger various OOM exceptions in other parts of the code.

Simple request causing 662.2 megs to be allocated:
curl "http://localhost:7874/nxt" -d '{"protocol": 1, "requestType": "processBlock", "version": 1, "blockTimestamp": 666, "timestamp": 666, "previousBlock": "666", "numberOfTransactions": 0, "totalAmount": 666, "totalFee": 1, "payloadLength": 662200000, "payloadHash": "deadbeef", "generatorPublicKey": "deadbeef", "generationSignature": "deadbeef", "blockSignature": "deadbeef"}'

* Tested against 0.5.0

I actually posted that earlier in this thread but everyone ignored it (https://bitcointalk.org/index.php?topic=397183.msg4354551#msg4354551) .

[Jaguar0625]

What's the feature? To make it easy for NXT to be stolen?

https://bitcointalk.org/index.php?topic=345619.msg4352067#msg4352067

I don't understand your answer. Are you saying that there is less security so darknxt can be taken from accounts without public keys?

[klee]

Jaguar post your id (or pm)...

[Jaguar0625]

You have to think like an attacker. They can do this by producing otherwise-valid blocks with high difficulties to knock out most of the network.

What do u mean?

I could be wrong, but it seems like some of the responses here assume a system of well-behaved participants. For threat-modeling you need to think like an attacker and how best to compromise the system.

For example, an attacker that wants to take over the NXT network could create a reasonably-looking block (e.g. it has a valid sender, recipient, password, etc.) and modify it slightly so that it difficulty is orders of magnitudes higher than the last block. All other nodes should accept his block because of the higher difficulty but nodes sending other blocks at that time would be blacklisted (for sending lower-complexity blocks). If the network was flooded with rouge agents sending high complexity blocks, I think it's possible for them to take over the network. And if they own the network they can do pretty much anything.

[bidji29]

What's the feature? To make it easy for NXT to be stolen?

https://bitcointalk.org/index.php?topic=345619.msg4352067#msg4352067

I don't understand your answer. Are you saying that there is less security so darknxt can be taken from accounts without public keys?

yes. They made it that way so DarkNXt are minable in the future. And not lost forever

[Jaguar0625]

Jaguar post your id (or pm)...

14544444716689899421 Thanks!