Curve Finance Hack: A Deep Dive into the Vyper Vulnerability

An Expert’s Take on The Curve Finance Hack

A Couple Of Words About Dexaran

Dexaran is the founder of the EthereumCommonwealth team, security auditor, and hacker (he has DDOSed EOS mainnet in 2019 and froze its DAPPs for half a year, and drained the Chintai exchange).

Founder of Callisto Network Security Auditing organization that has audited more than 300 smart contracts, and not even a single one that we reviewed was ever hacked.

EthereumCommonwealth built the first online version of the Vyper compiler on 11 August 2017. Here is the report. Here is this online Vyper compiler prototype.

Dexaran has participated in the development of the Vyper programming language.

In 2020, he wrote an article that highlighted the problems of new programming language development and described what happened to Curve Finance 3 years before it actually happened.

Vyper was abandoned because:

1. It solves no real problems.
2. Developing a new programming language and/or compiler requires high expertise in compiler development — the Ethereum team doesn’t have any compiler developers who participated in the real compiler development (GCC or LLVM).
3. From a security point of view, it is much better to rely on existing solutions if they don’t have any critical problems that need to be addressed.

In Short

One guy decided to create a new programming language (which was utterly unnecessary, to begin with), even though he had no experience developing programming languages. After that, some other guy created a compiler for it, even though he wasn’t a professional compiler developer. Then some third guy built a system that managed a massive amount of his users’ funds using all that stuff, and it all broke.

 

 

Finally, they stated, “No need to point fingers at each other,” but from a security perspective, it’s the complete responsibility of the guy who decided to pick exactly THAT insecure toolchain to build critically important software with it.

What Happened?

A vulnerability was discovered in a Vyper compiler, which allowed hackers to drain $62M worth of funds.

The Development Of A New Programming Language Is A Big Mistake & A Security Threat

 

Dexaran wrote the article “Development of a new programming language for smart contracts is a big mistake” in 2020, and the Callisto Security Department strongly recommends all blockchain developers review it before delving into any code.

With the hack of Curve Finance, it became evident why this practice is a mistake.

Below is the most important idea from the article:

Developing a new compiler is extremely specific task that requires highly qualified team experienced in exact this area. All the custom compilers are orders of magnitude worse compared to the existing ones such are GCC or LLVM. This should be noted that GCC is in development for 32 years already while LLVM is 17 years in development. If someone decides to use a custom programming language for smart contracts and developed a new compiler for it then it is reasonable to expect that it will take about 15 years to bring this tools to the level of performance and security of nowadays LLVM assuming that a team of highly specialized experts is dedicated for this task.

Were Vyper compilers developers going to outperform LLVM which was in development for 17 years and had a dedicated expert working on it? Were they going to outperform it in 4 years without any expertise in the area? This overlooks crucial security rules in development.

What Has Gone Wrong?

Everything…

1. Vyper programming language – there was totally no point in creating it in the first place. What is more important, however, is that this programming language was created without involving any security experts/experts in programming language & compiler development.
2. Vyper compiler development –  This is a very specific, cumbersome, and risk-involving task. Also done without any expertise in the area.
3. Utilizing an immature toolchain – Build critically important parts of the financial application with an immature toolchain. Whose genius idea was to take an untested toolchain and throw users’ funds into it?

Security Recommendations

1. Read this article. Thoughtfully, it explains everything that happened three years before it happened.
2. Stop the development for the sake of development. Do not implement something unnecessary. Do not put it on the table. Every line of new code has a chance to have a vulnerability or bug.
3. Do not use potentially insecure software. Stick to the tested options if it is not known to have serious problems.
4. Do not use software having security problems just because everyone uses it.
5. If you don’t have expertise in some area — do not think you will outperform experts. Instead, hire experts or consult with them at least.
6. Treat security seriously. VERY SERIOUSLY. You are dealing with your users’ funds. Think of it as you are dealing with people’s lives.
7. Choose your auditors wisely. Your security auditor must be (1) transparent and (2) competent. There are a lot of “marketing auditors” nowadays. Use common sense — if your auditor is known for having several contracts hacked after being assigned a “secure” stamp, maybe it’s not the best auditor.