Bitcoin Forum
May 19, 2019, 04:03:24 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 [32] 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 »
  Print  
Author Topic: Nxt source code flaw reports  (Read 113039 times)
gsan1
Newbie
*
Offline Offline

Activity: 50
Merit: 0


View Profile
January 07, 2014, 06:34:05 PM
 #621

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?
Get alert of price pumps/dumps beforehand 74% average Win Rate
reported by our users
TRY NOW!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2086
Merit: 1007

Newbie


View Profile
January 07, 2014, 06:40:19 PM
 #622

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
Newbie
*
Offline Offline

Activity: 28
Merit: 0


View Profile
January 07, 2014, 06:45:30 PM
 #623

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
Legendary
*
Offline Offline

Activity: 2086
Merit: 1007

Newbie


View Profile
January 07, 2014, 06:53:46 PM
 #624

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
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
January 07, 2014, 07:01:53 PM
 #625

Hey gang,

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

Quote
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 Wink

[edit]
Thanks CfB and JLP for the quick fix of the negative budget, starting to browse thru the decompiled code now. Smiley
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2086
Merit: 1007

Newbie


View Profile
January 07, 2014, 07:06:12 PM
 #626

Hey gang,

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

Quote
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 Wink


This issue is fixed as well.
etlase3
Newbie
*
Offline Offline

Activity: 28
Merit: 0


View Profile
January 07, 2014, 07:20:16 PM
 #627

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
Hero Member
*****
Offline Offline

Activity: 910
Merit: 1000



View Profile
January 07, 2014, 07:21:14 PM
 #628

 Roll Eyes
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2086
Merit: 1007

Newbie


View Profile
January 07, 2014, 07:25:01 PM
 #629

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
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
January 07, 2014, 07:30:22 PM
 #630

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
Legendary
*
Offline Offline

Activity: 2086
Merit: 1007

Newbie


View Profile
January 07, 2014, 07:35:36 PM
 #631

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
Newbie
*
Offline Offline

Activity: 28
Merit: 0


View Profile
January 07, 2014, 07:40:20 PM
 #632

Sorry, but I disagree that ur example is relevant.

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

Activity: 1174
Merit: 1002



View Profile
January 07, 2014, 07:56:00 PM
 #633

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
Legendary
*
Offline Offline

Activity: 2086
Merit: 1007

Newbie


View Profile
January 07, 2014, 07:57:45 PM
 #634

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
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
January 07, 2014, 08:18:08 PM
 #635

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
Legendary
*
Offline Offline

Activity: 2086
Merit: 1007

Newbie


View Profile
January 07, 2014, 08:25:24 PM
 #636

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
Newbie
*
Offline Offline

Activity: 11
Merit: 0


View Profile
January 07, 2014, 08:29:42 PM
 #637

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
Legendary
*
Offline Offline

Activity: 2086
Merit: 1007

Newbie


View Profile
January 07, 2014, 08:35:26 PM
 #638

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
Full Member
***
Offline Offline

Activity: 238
Merit: 100



View Profile
January 07, 2014, 08:37:59 PM
 #639

...
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
Legendary
*
Offline Offline

Activity: 2086
Merit: 1007

Newbie


View Profile
January 07, 2014, 08:40:35 PM
 #640

...
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.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 [32] 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!