Feel free to discuss or ask questions below!
“By the way the pimple is gone.”
Solidity appears similiar in coding style to C++ so if reader understands C++ they can understand Solidity. Correct statement?
I have a question, it was explained a bit in the article of the assignment before, but still I kinda wanna know the implementations and some more info:
If you find a contract which produces tokens, and you exploit it and give yourself an infinite amount of those tokens. You can trade them and get free Bitcoin/fiat with it, if the token is tradeable, right?
Are there actually any legal regulations about that? lol
Yes you can but you will have to defend it offchain, you will probably be accused of felony ,
If you want to trade it against fiat good luck trying to avoid KYC and chainanalysis alerts
Personally i would say this is a general security issue in the EVM,
and if it is not fixed there, we will see this kind of bug over and over again.
An overflow should always throw an runtime exception !
You could use a functional language to do so for example scilla (for the Zilliqa blockchain ) is handling it.
I don’t really agree with you as some hashing function are using the overflow as a way to limit collision
Thanks for your feedback on this.
I think a functional language would be the first choise for such critical software, but it has a bigger entry barrier for most developers (cause you first need to twist around your mind to understand the paradigms of functional programming and get used to it). Anyway i think this is not the point here because the language itself is not relevant at all.
Doesn’t matter which language you use, finally the compiler translates it to bytecode.
Regarding the overflow (problem ?) i still don’t agree.
I haven’t went through the document in detail (too much after normal working day ), so i may be wrong,
but i see that this is reagarding a specific hash search functionally using an overflow table,
meaning the overflow data is written in a controlled manner to a memory location that you can still access and is not overwiting unallocated memory locations.
This is basically not an overflow for me. Or a better word would be “memory overflow” to be more precise.
If it is something you can use in a controlled manner you should be able to access the overflow data.
(For me) an overflow is when you write data to a memory location that doesn’t have enough space to hold the value. This is basically what can happen when you work with unmanaged code (for example in C using pointers).
Basically you write something to memory, overwriting memory that maybe part of another variable.
This also means you do not have access to the overwritten memory location afterwards (if you don’t trick around with pointers and know exactly where the data was written to).
It don’t know if the EVM just cuts the overflow data away (therefore protecting the memory at least),
but then the data is lost and cannot be accessed any more, meaning that you can’t even implement the described hash search algorithm.
What do you think about that ?
Am i thinking in a complete wrong direction ?
Scilla is not compiled it’s an interpreted language, and because it’s strongly type ( ocaml style) an integer overflow will cause a run-time exception. The language is important because at the end it depend how the code will be executed.
True it wasn’t the right example
I had to use intentionally an overflow using a variant of the bernstein algo (DJB) to hash an ipv6 couples (src-dst), and the distribution was more efficient. I found an other example why it could be use:
uint hash(String x, int a, int p)
uint h = INITIAL_VALUE
for (uint i=0 ; i < x.length ; ++i)
h = ((h*a) + x[i]) mod p
This Rabin-Karp rolling hash is based on a linear congruential generator. Above algorithm is also known as Multiplicative hash function . In practice, the mod operator and the parameter p can be avoided altogether by simply allowing integer to overflow because it is equivalent to mod ( Max-Int-Value + 1) in many programming languages.
The original message was talking about an exploit which give you an “infinit amount of token”.
So for me it easier using an integer overflow exploit than a buffer overflow.
I first though it was not possible to allocate memory page as you do in C because there is no pointer, and Solidity doesn’t give you any tools like malloc or a mmap to map the memory to a pointer.
But by looking online you make me learn a new thing it is actually possible to use pointer and to allocate memory manually with assembly.
The answer of the post is really interesting
Also found this really recent buffer overflow (actually overlapping ) case
Layout in Memory
Solidity reserves four 32-byte slots, with specific byte ranges (inclusive of endpoints) being used as follows:
0x3f(64 bytes): scratch space for hashing methods
0x5f(32 bytes): currently allocated memory size (aka. free memory pointer)
0x7f(32 bytes): zero slot
The zero slot is used as initial value for dynamic memory arrays and should never be written to (the free memory pointer points to
Looking at the layout memory, you will not be able with a buffer overflow to modify the balance or the number of token as in my understanding they will be located in the lower range addresses.
But i still need to dive dipper into it
I’m at this lesson: https://academy.ivanontech.com/products/ethereum-smart-contract-security/categories/1691818/posts/5680697( Solidity Vulnerability Demonstrated )
I made exactly like Ivan made in the lesson but I get this error when I press batchSend: https://screenshots.d.pr/isRiBI
“transact to overflow.batchSend error: Error encoding arguments: Error: invalid number value (arg=”", coderType=“uint256”, value=“0x80000000000000000000000000000000000000000000000000000000000000000”, version=4.0.47)"
Is this vulnerability solved?
@richmond8255. Yes, that is correct both are based object oriented programming.
Looks like you have an extra zero in your value. Try that: 0x8000000000000000000000000000000000000000000000000000000000000000
Nice to read
I tried the same code of overflow with its vulnerabilities, and I sent a big number to 2 addresses, but the transaction didn’t work( it should overflow ), instead of that I got an error (I don’t understand why it doesn’t overflow ) @ivan :
transact to Overflow.batchTransfer errored: VM error: revert. revert The transaction has been reverted to the initial state. Note: The called function should be payable if you send value and the value you send should be less than your current balance. Debug the transaction to get more information.
Hey @Oussama, hope you are great.
Now it could be that you miss to assign “payable” to the function. If you share your code i could have a better understanding of the issue, but apparently the console said that “called function should be payable”.
If you have any more questions, please let us know so we can help you!
Does the smart contract not already have a fixed number of tokens available? Pretend a contract has 100 tokens. If someone exploit batch overflow for 1000 tokens, where do the extra tokens come from!?
Does the smart contract not already have a fixed number of tokens available
Not by default.
The developers decide if the tokens will be capped to a certain number or unlimited.
Hi there, did i get it wrong or the overflow/underflow issue is fixed in the 0.8 version of solidity ?
Is there a need for SafeMath using this version?