Nxt source code flaw reports

[gsan1]

Transaction is sent but rejected by peers coz it's too far in the future. Adjust ur time by minus 2 hours and check if u get any lost transaction.

What time do you mean? The server time, on which the nxt client is running?

Time of the machine NRS server part runs on.

The NRS server runs on debian. The OS gets its time from timeservers and it is correctly. So why should I set this time manually back, so that transactions get sent?

[1713984179]

1713984179

[1713984179]

1713984179

[1713984179]

1713984179

[Come-from-Beyond]

The NRS server runs on debian. The OS gets its time from timeservers and it is correctly. So why should I set this time manually back, so that transactions get sent?

To make sure that time/timezone is incorrect.

[etlase3]

I guess I was wrong about the first 64-bits not being cryptographically secure, but we're still talking about 64 bits.

I still have not heard an answer as to why NXT isn't using (at least) 160-bit hashes like Bitcoin.

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

This is a terrible answer to the question. 64-bits of protection is a design flaw.

[Come-from-Beyond]

I guess I was wrong about the first 64-bits not being cryptographically secure, but we're still talking about 64 bits.

I still have not heard an answer as to why NXT isn't using (at least) 160-bit hashes like Bitcoin.

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

This is a terrible answer to the question. 64-bits of protection is a design flaw.

Thank u for ur competent opinion.

[ricot]

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

Isn't this memory garbage collected?

Yes, the allocation will get garbage collected, but don't rely on this for this kind of operations. The solution is very easy here.. there is a check that should be done against the max payload constant and it is done, but too late in a different function. As soon as you call 'processBlock', a first allocation will occur.

If I trigger this constantly on a node (let say localhost), any concurrent 'new' operation will fail with an OOM exception before memory is exhausted by this issue. That means I can easily DoS any node I want without using that much bandwidth. An attacker could bring down the entire network using this trick. This is a critical issue.

And if you fix that one, you can also fix this: https://bitcointalk.org/index.php?topic=397183.msg4316634#msg4316634
Nearly the same issue, just different parameter

[edit]
Thanks CfB and JLP for the quick fix of the negative budget, starting to browse thru the decompiled code now.

[Come-from-Beyond]

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

Isn't this memory garbage collected?

Yes, the allocation will get garbage collected, but don't rely on this for this kind of operations. The solution is very easy here.. there is a check that should be done against the max payload constant and it is done, but too late in a different function. As soon as you call 'processBlock', a first allocation will occur.

If I trigger this constantly on a node (let say localhost), any concurrent 'new' operation will fail with an OOM exception before memory is exhausted by this issue. That means I can easily DoS any node I want without using that much bandwidth. An attacker could bring down the entire network using this trick. This is a critical issue.

And if you fix that one, you can also fix this: https://bitcointalk.org/index.php?topic=397183.msg4316634#msg4316634
Nearly the same issue, just different parameter

This issue is fixed as well.

[etlase3]

Thank u for ur competent opinion.

Your answer is borderline incompetent, so it doesn't deserve much.

http://crypto.stackexchange.com/questions/2319/what-is-the-largest-performed-possible-bruteforce-attack-to-date

64-bit symmetric keys were broken in 2002.

[bitcoinpaul]

 

[Come-from-Beyond]

Thank u for ur competent opinion.

Your answer is borderline incompetent, so it doesn't deserve much.

http://crypto.stackexchange.com/questions/2319/what-is-the-largest-performed-possible-bruteforce-attack-to-date

64-bit symmetric keys were broken in 2002.

Sorry, but I disagree that ur example is relevant.

[ricot]

Ok, I went thru the decompiled code, and I think, you didn't improve it by much, because the new code now has a nice DOS attack vector...
If I send you a request that forks the blockchain just one block before the current one and I lie about cumulated difficulty, you'll automatically do a complete rescan of the blockchain. This takes (I guess) more than a second, so the next thread for requesting the blockchain will already wait (because of the synchronized block), so if there the same happens, your client will keep being blocked.
So how do you exploit that?
Well, you need 300ish servers, publish their addresses to the network, have all of them appear in good shape (maybe backed by some accounts so they get nice hallmarks), and have them send the wrong cumulative difficulty and one block to add.
The chance that there will be a request to one of your servers is quite high and the blacklisting is removed after 300s, so they'll be used again. But since the client will probably take way more than a second, you can even get by with fewer servers...
And you'll cause high cpu load and slow (or old) responses for the attacked peer, plus a lot of disk reads and writes.

Actually, on that note: Do you check anywhere if a hallmark appears twice? If not, you could back all of your servers with the same big account which would give them a nice bonus in being chosen for the post request...

[Come-from-Beyond]

Ok, I went thru the decompiled code, and I think, you didn't improve it by much, because the new code now has a nice DOS attack vector...
If I send you a request that forks the blockchain just one block before the current one and I lie about cumulated difficulty, you'll automatically do a complete rescan of the blockchain. This takes (I guess) more than a second, so the next thread for requesting the blockchain will already wait (because of the synchronized block), so if there the same happens, your client will keep being blocked.
So how do you exploit that?
Well, you need 300ish servers, publish their addresses to the network, have all of them appear in good shape (maybe backed by some accounts so they get nice hallmarks), and have them send the wrong cumulative difficulty and one block to add.
The chance that there will be a request to one of your servers is quite high and the blacklisting is removed after 300s, so they'll be used again. But since the client will probably take way more than a second, you can even get by with fewer servers...
And you'll cause high cpu load and slow (or old) responses for the attacked peer, plus a lot of disk reads and writes.

Actually, on that note: Do you check anywhere if a hallmark appears twice? If not, you could back all of your servers with the same big account which would give them a nice bonus in being chosen for the post request...

I would leave finding a solution to this problem to guys who will clone Nxt. With TF this attack is impossible.
PS: If u use the same account to hallmark these 300 servers then each of them will have 1/300 of the balance.

[etlase3]

Sorry, but I disagree that ur example is relevant.

There isn't really any room to disagree, 64 bits is not safe.

[LiQio]

Sorry, but I disagree that ur example is relevant.

There isn't really any room to disagree, 64 bits is not safe.

I guess what Come-from-Beyond means is that equivalent key sizes do not imply equivalent security and vice versa

[Come-from-Beyond]

Sorry, but I disagree that ur example is relevant.

There isn't really any room to disagree, 64 bits is not safe.

Would u be so kind to not bother me with ur comments until u read the code and get its logic?

[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.

[Come-from-Beyond]

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

[iscy]

Sorry, but I disagree that ur example is relevant.

There isn't really any room to disagree, 64 bits is not safe.

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

It can only be exploited if an account doesn't have an associated public key. In that case, the issue is real. 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.

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... You know, everything can be "cracked" or "bruteforced" in cryptography. However, if the time taken to bruteforce is more expensive or require more time than the validity of the data, then we consider this safe.

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. It doesn't require much modifications on the current codebase to do this.

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...

[Come-from-Beyond]

Sorry, but I disagree that ur example is relevant.

There isn't really any room to disagree, 64 bits is not safe.

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

It can only be exploited if an account doesn't have an associated public key. In that case, the issue is real. 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.

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... You know, everything can be "cracked" or "bruteforced" in cryptography. However, if the time taken to bruteforce is more expensive or require more time than the validity of the data, then we consider this safe.

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. It doesn't require much modifications on the current codebase to do this.

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...

Thank u for the explanation. I have zero tolerance to guys who think they r the smartest. That's why my last reply to etlase3 may look a little bit rude.

[opticalcarrier]

...
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. It doesn't require much modifications on the current codebase to do this.
...

but that would leave open an attack for a spammer to megaspam the blockchain with millions and millions of empty accounts

[Come-from-Beyond]

...
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. It doesn't require much modifications on the current codebase to do this.
...

but that would leave open an attack for a spammer to megaspam the blockchain with millions and millions of empty accounts

This will be fixed by a special payment transaction that sends money to a full 256-bit address.