author: aman
Blog I - Part III - Day 03
As you have already seen, how critical the small bugs could be. The fatal injury they can cause to your data privacy can’t be overlooked.
Creating a fault free system, is extremely tough, and this is what the world or your own startup demands from you. There has been a boom in AI startups. As simple as that, create an AI application(not talking about a few very intellectual startups like GENOME) and make your startup. Well, what if I tell you, even that one particular startup at some stage have to go through a few critical checks regarding privacy and security.
Well, this blog will cover a few things regarding What the world is currently doing against these bugs and vulnerability things.
In this micro-blog
- What am I talking about?
- Why am I talking about it?
- Have you heard before? (The “goto fail;”, Heartbeat, Meltdown, Spectre)
- What the world is upto against such __ ?
- Basic Challenges faced
- Unimportant sounding complete terms
- Motivation behind
What the world is upto against such __ ?
Okay, turning over to my fav Blockchain, suppose you have created your very own Smart Contract, and ready to get into the business with quick trading of your Coins. But, how would you ensure that your smart contract is “ACTUALLY” safe to trade coins? Or it doesn’t leak the information to a people where it shouldn’t.
Let me tell you about an interesting case, The DAO Attack. If you have a little knowledge about the smart contract[1], you might be knowing that they are the simple rules governing an application on Blockchain. If not, watch a video.
The Decentralised Autonomous Organisations(DAO) is considered to be the very first large-scale Ethereum Application(the most famous Blockchain Application building and deployment platform). Let me first tell you about this very error that the smart contract creator made:
In ethereum blockchain, as these so called smart contracts are “public” they can be called by any other smart contract, anytime. So when in contract(look at the flow), you call a function bankAddress.withdraw(), the flow goes to sender.call.value(), which actually sends some currency(ETHER - the crypto Ethereum works on), to the contract on right-side. The flow goes to the payable given below, which is a kind of Necessary for the contract to accept the payment. If you look closely, the right hand contract, has another withdraw function!!!!!
This is called as the Reentrancy attack!
Registered in the swcregistry (Smart Contract Weakness Classification and Test Cases).
Exciting, isn’t it? This thing will actually make a loop of payments, without deducting the balance on the very next line of the left-contract.
This small bug actually drained of cryptocurrencies worth around $50 Million to the attacker’s account before the maintainers could fix it.
*you can have a look at this very video
A whole lot of research scientists are working on to preventing any such vulnerabilities and analysing the risks involved.
A small excerpt[2], to tell you people about the risk, vulnerabilities & bugs.
“Vulnerability (weakness) is a gap in the protection efforts of a system, a threat is an attacker who exploits that weakness. Risk is the measure of potential loss when that the vulnerability is exploited by the threat e.g. Default username and password for a server – An attacker can easily crack into this server and compromise it.”
Now what the people are doing actually!
When the Modern Computer Science was actually developing(since 1980s or even earlier), there was a whole lot of research in defining standard definitions and notations, that is applicable to almost every computer science concepts. These notations involves the Formal Languages and the definitions of systems, states, properties, hyperproperties etc. are still followed to define secure systems standards.
The researchers usually rely on the program analysers, which actually look at he dark corners of the program and tell about the vulnarabilties, based on which the risk involved is decided.
There are always certain properties & conditions a program should follow and a program should not follow. For Ex. in DAO Reentrancy, it was analysed to be deducting the amount more than one time, while calling the withdraw function. This condition, that the contract should never transfer more than withdrawn amount, is framed within the program analyser, and checked for the failure. Such framed conditions are called as SATISFIABILITY. Softwares called SAT-SMT solvers are build for that purpose.
There are certain techniques, which are followed to detect vulnarabilities and calculating risks involved with these systems.
- Symbolic executions (looking for the flow of the program to check the failure points)(these are generally COMPUTATIONALLY expensive, so there are methods to make them more efficient)
- Model Checking Techniques ()
- Fuzzing systems , etc.
I have planned to write separate complete blogs for this(program analyser, formal methods, blockchain vulnerabilities) in the upcoming blogs(other than this very blog) in the upcoming days of this #20 Days series. Security tools available for Ethereum
Thanks for your time.
Cheers!!!