Are you a Cosmos developer wondering how to secure your project? At Halborn we look at a lot of Cosmos projects to make sure that the protocol works as expected, has robust errors detection, and safely handles user funds.&nbsp;We wanted to share some of our experience with performing code review on a wide range of Cosmos projects and distill our knowledge into some helpful tips that will assist you during the development process.Below are the top five most common vulnerabilities and issues that we look for when checking out a new Cosmos project.<h2>1. Panics used for error handling</h2>When developing a project, typically a developer wants to spend their time developing new features and error handling comes second. In the heat of the moment when developing a hot new feature, it’s tempting to skip error handling, at least temporarily, in order to focus on completing the feature. A developer in a hurry might use the panic function in Go to tell the code to abort execution when handling an error case. In some cases this is appropriate: if there is truly an unrecoverable error, then it may be correct to stop execution entirely.&nbsp;However, this can be problematic for a number of reasons. Panic does not allow the program to handle errors gracefully. In many cases it’s better to handle the error, log it, and print a helpful error message for the user or the validator software indicating what went wrong. Ideally, execution should continue where possible to ensure a smooth user experience.In general panic can cause security problems in Go code because it indicates that a serious problem has been encountered. From an attacker‘s perspective, a panicking program can indicate a potential attack vector. When developing exploits, an attacker&#8217;s methodology will begin with discovering a crash and escalating this into a full exploit.In the context of Blockchain software, a panic can have a very pronounced impact. For more information on this topic we invite you to check out another article we wrote, ‘<a href="https://halborn.com/dont-panic-how-improper-error-handling-can-lead-to-blockchain-hacks/">Don’t “Panic”: How Improper Error-Handling Can Lead to Blockchain Hacks</a>’, that goes into detail about why you should avoid using panic.We recommend using proper error handling instead of panic. Panic should be used only in exceptional situations where there’s absolutely no way for code execution to continue safely.<h2>2. Using components with vulnerabilities</h2>A classical piece of security wisdom is that all software should be kept up-to-date. The reason for this is that outdated or unsupported software will not include the latest performance improvements or security patches compared to newer versions.&nbsp;In the context of Cosmos, these components include:&nbsp;<ul><li>The CosmosSDK</li><li>Go libraries that the project uses</li><li>The version of the Go programming language itself</li></ul>As software ages, it typically becomes vulnerable as hackers and security researchers examine it for flaws. New techniques will be developed that render software vulnerable to attack even if it was believed to be secure when it was released.This is especially important in a Blockchain context because new attack vectors are being developed all the time. These can range from relatively simple bugs to critical issues that can have serious effects on the health of a chain. A timely example includes a vulnerability discovered in the CosmosSDK software following the <a href="https://halborn.com/explained-the-bnb-chain-hack-october-2022/">Binance hack</a>. The Cosmos developers issued an <a href="https://forum.cosmos.network/t/ibc-security-advisory-dragonberry/7702">urgent security notice</a> informing all validators to update their software in light of this critical issue.&nbsp;There are a variety of tools that can be used to monitor your project’s dependencies for outdated components, and we recommend using them as well as enforcing their use within a CI/CD environment.&nbsp;It is also suggested to monitor the repository of CosmosSDK and other popular sub-components for the latest software releases and bug fixes. Joining a project’s social media communities and paying attention to their published announcements is also an effective way to stay informed of any potential issues and fixes.<h2>3. Sources of non-determinism</h2>It is imperative that Blockchain software has a deterministic state. This is because all validators must be able to perform the same calculations and reach the same output so that they can agree on the state of the network. When consensus fails, the network will halt as there is no safe way to coordinate state among the validators.<h3>Iterating over a map</h3>A common example of non-determinism in Cosmos projects occurs when iterating over a ‘map’ which is analogous to a dictionary or hashmap in other programming languages. Map orderings are not deterministic. This means that if a loop is used to list the elements of a map, the loop could traverse the elements of the map in a different order for every execution even when the data in the map has not changed. If this happens in a consensus method or storage, such as <a href="https://docs.cosmos.network/master/building-modules/beginblock-endblock.html">BeginBlocker and EndBlocker</a>, the validators may not be able to agree on state and the chain could halt.Earlier this year, a bug in Cosmos allowed an attacker to <a href="https://blockpane.medium.com/who-crashed-jun%C3%B8-3cd889b3524">halt the Juno network</a>. The attacker was able to submit malicious transactions via Cosmwasm contracts that caused non-determinism in the network.To understand this a little better, let’s look at an example. Consider the following code:                                                                                                                                                 &#8220;`go&nbsp;&nbsp;&nbsp;&nbsp;for lpAddress, rewards := range liquidityProvidersMap {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;coinToTransfer := sdk.NewCoin(&#8220;HAL&#8221;, sdk.NewIntFromBigInt(rewards.BigInt()))&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;err := k.bankKeeper.SendCoinsFromModuleToAccount(ctx, &#8220;RewardModule&#8221;, lpAddress, sdk.NewCoins(coinToTransfer))&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if err != nil {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// Do error handling here&#8230;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}&nbsp;&nbsp;&nbsp;&nbsp;}&#8220;`Here we want to distribute some rewards from our module “RewardModule” to a group of liquidity providers. In order to do so, we iterate over a map that pairs liquidity provider addresses with the rewards they are owed and pay them one by one.A problem can arise here if our `RewardModule` has an insufficient balance and cannot pay all of the LPs. Let’s say we have three LPs and each is owed 100 units of the coin “HAL” but the module only has a balance of 200 HAL. Our loop will pay two of the LPs 100 HAL each and then trigger an error when trying to pay the third LP because the module does not hold enough HAL to be able to complete the transfer.This error could escalate into a chain halt because of non-determinism. Since the map `liquidityProvidersMap` is not ordered, different validators may traverse it in a different order.&nbsp;The possible orderings for the LPs are as follows:<ul><li>{1,2,3}</li><li>{1,3,2}</li><li>{2,1,3}</li><li>{2,3,1}</li><li>{3,1,2}</li><li>{3,2,1}</li></ul>As the validators run the code, they will pay the rewards to different LPs and reach an error when trying to pay the third one in their given ordering. There is a high chance that they will pay rewards to different LPs and so when it comes time to establish a consensus about the state of the chain, they will report different results. When this happens, the chain will halt.<h3>Non-determinism due to accessing the system time</h3>Non-determinism can occur in other ways as well. Another common example is using the `time.Now()` function in order to grab the system time from the operating system. Because all of the validators will execute this function at slightly different times, this function will give different results for each validator. This too can lead to consensus issues if some logic in a consensus function relies on the result of the time function. In this scenario, it’s recommended to use the block time of the chain to represent time rather than the system clock.<h2>4. Business logic issues</h2>Many of the issues we’ve discussed so far arise from the program reaching a bad error state that causes a problem in the app chain operation. In contrast, logic issues arise when a program executes ‘correctly’ and yet behaves in a way that is against the intentions of the developers.When logic issues come up, there will be no error message printed to developers or users informing them that a problem has occurred. Why? Simply because, to the computer, it looks like everything is fine. It is only when we humans interpret the result that we can identify whether an issue has occurred.&nbsp;We can explore logic errors by considering the following scenario: what happens if an attacker is able to create a liquidity pool in a DeFi protocol that uses a spoofed token?&nbsp;Say this protocol has its own token ‘SwapCoin’ and it allows liquidity providers to create pools that pair SwapCoin with other tokens. In order to enforce this, a developer might write a function to ensure that, when a liquidity provider creates a new pool by submitting an amount of some pair of tokens, that one of these tokens has the name ‘SwapCoin’.That function might look like this:&#8220;`gofunc (h CreatePoolHandler) handleCreatePool(ctx cosmos.Context, msg CreatePool) error {&nbsp;&nbsp;&nbsp;&nbsp;assetX, assetY, err := h.mgr.Keeper().ParseCreatePoolMsg(msg)&nbsp;&nbsp;&nbsp;&nbsp;// Check that either assetX or assetY is SwapCoin&nbsp;&nbsp;&nbsp;&nbsp;if !strings.EqualFold(&#8220;SwapCoin&#8221;, assetX.Denom) &amp;&amp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;!strings.EqualFold(&#8220;SwapCoin&#8221;, assetY.Denom)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// return error&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}&#8220;`At first this code may look safe, but there is actually a logic issue here. The <a href="https://pkg.go.dev/strings#EqualFold">EqualFold function in the strings package</a> performs a case-insensitive comparison. This means that it will accept values that resemble ‘SwapCoin’ with different capitalizationg, e.g. ‘sWapCoin’, ‘swapcoin’ and so on.This behavior allows an attacker to attack the protocol. This attacker could create a token called ‘sWapCoin’ and use it in place of the native token. This has the effect of allowing them to forge tokens and perform any actions within the project’s liquidity pools as though they really had authentic SwapCoins.To profit from this, an attacker could drain value from an existing pool that pairs SwapCoin with Atom. They could use ‘sWapCoin’ to swap for Atom and then walk away from the project. In the end, the attacker walks away with the funds while simultaneously undermining the economics of the project as they have effectively inflated the supply of SwapCoins, at least for the purposes of trading between liquidity pools.This is just one example. Logic errors by definition are hard to generalize about because there are many ways in which they manifest. Thus, it is also difficult to provide a general recommendation for fixing logic errors because they are highly dependent on what the developer wishes to occur.&nbsp;The best way to handle these sorts of problems is to write extensive unit tests. Unit tests can encode a developer&#8217;s intentions by supplying example values and ensuring that the code does the right thing. It can be helpful to compare software implementations to design documents to ensure that the code does what it’s supposed to.We advise writing “adversarial tests” in addition to ordinary unit tests. This means providing strings where numbers are expected (and vice-versa), using signed integers in place of unsigned integers,&nbsp; and so on. The developer should also try especially high or low values, switch around character sets for strings (from ASCII to UTF-8),&nbsp; etc. The sky&#8217;s the limit! The more imaginative these tests are, the more likely it is that a developer will discover a logic error before an attacker does.In the long term, developers should also implement <a href="https://halborn.com/what-is-fuzz-testing-fuzzing/">fuzz testing</a>. Fuzzing is a technique for testing software that involves automatically generating mangled data and providing it as inputs to various functions within the code base. This has the effect of unearthing logic errors and strange crashes during the development process.Cosmos provides <a href="https://github.com/cosmos/cosmos-sdk/blob/main/docs/docs/core/12-simulation.md">simulations</a> which embed a form of fuzzing within your project without the need for external tools. Simulations work by testing against <a href="https://github.com/cosmos/cosmos-sdk/blob/main/docs/docs/building-modules/07-invariants.md">invariants</a>, i.e., rules in your program that should never be broken. An example of an invariant is ensuring that a user’s supply of a given token does not exceed the total supply of that token throughout the whole ecosystem. Clearly, this should never happen in well-functioning code.&nbsp;Extensive use of simulations and invariants will go a long way to writing more secure Cosmos software.<h2>5. Overflow, underflow, and casting</h2><h3>Overflow and Underflow</h3>Time for a bit of a math lesson before we return to security.Integers in computers can only increase to a certain limit because they are represented by a fixed number of bits in a computer. If you are using an integer with 8 bits for example, the maximum value for that number is 255 which corresponds to all of the bits being set to 1. This is because all we can do is change bits from 0 to 1; if they’re all set to 1, there’s no way to increase the number.Now, what happens when we add two numbers together? Say we try to add 200 to 200. In the normal world, we know this is 400. But when working with integers with a size of 8 bits, we can’t store values higher than 255. So what happens?&nbsp;This scenario is called an overflow. Like an odometer in a car, the number wraps around once we reach the maximum. We add numbers to 200 until we reach 255, then start over at 0. The result is the remainder of x + y / int_max_size. In this case, 200 + 200 / 255 gives us a remainder of 145.To sum up, when adding two numbers that are close to the maximum size that an integer can hold, we can sometimes end up with a much lower number than we expected. The same is true for subtraction, but with the opposite result: subtracting one number from another will give us a very high result rather than a negative result. This is called underflow.<h3>Casting </h3>The above is true for unsigned integers. We can represent negative numbers by interpreting a set of bits as a signed integer. When we do this, a single bit is used to represent whether the number is positive or negative. Since this bit is now representing some information about the number rather than the number itself, the range of what numbers we can represent changes.In the example where we are using 8 bits for our numbers, the range for an unsigned integer is 0 to 255, and the range of the negative number is -127 to 127. In both cases we can represent a total of 256 different values. <a href="https://en.wikipedia.org/wiki/Signed_number_representations#Sign%E2%80%93magnitude">Check out this Wikipedia link </a>for more information on how numbers are represented at the bit-level.An important consequence here is that a developer can specify whether a number should be treated as signed or unsigned. For example, if a value of 128 in an unsigned integer is treated as a signed integer, then its value becomes -1!<h3>Security Implications</h3>If we put all of this together, we can see that operations like addition and subtraction are much more complicated than you might think. We also must be careful when telling the program whether we want a value to be considered signed or unsigned. In both cases we may end up with a very large number when we expected a negative number, and vice versa.Let’s think about a scenario where a user can only perform an action in the protocol as long as they have a sufficient amount of tokens. If they have a low balance and it is then decreased for some reason, it is possible that the value could underflow. Then if it is treated as an unsigned integer, the code could interpret them as having a very high balance. This could have huge consequences for the integrity of the program.Complicating things further, Go will not warn you if an overflow or underflow occurs. It also won’t be able to suggest to you whether you should treat a number as signed or not. CosmosSDK does provide helper functions that will panic rather than allow numbers to overflow or underflow. However, a developer has to use them in order to benefit from this. As we’ve seen, a panic could also cause other problems.When writing code for Cosmos project, it’s crucial to be aware of whether you want to work with an unsigned or signed integer and to check for overflows and underflows. In general it’s a good idea to avoid frequently switching between unsigned and signed integers so that it’s easier to reason about the state of the program.<h2>Conclusion</h2>These are just some of the complications that arise in Go and Cosmos code. We hope this survey of some of the most common, high-impact considerations has helped you to advance in your journey to write effective and secure code.We’re happy to help you review your source code for these types of errors and more. To talk to one of our blockchain experts about Cosmos source code reviews or any other Web3 security topics, drop us a line at halborn@protonmail.com.

Security Vulnerabilities Cosmos Developers

Security-Vulnerabilities-Cosmos-Developers.jpg

Web3 security firm Halborn provides an overview of the top 5 most common vulnerabilities and issues to look for in a Cosmos project.

Top 5 Security Vulnerabilities Cosmos Developers Need to Watch Out For&nbsp;

Most developers don’t dream of writing elaborate and exhaustive error-handling code.Instead, they like to focus on the “happy path,” that is, the way a program flows when every little bit of logic is proceeding according to plan.&nbsp;As security engineers and hackers, we are focused on the opposite. Instead of a pleasant stroll along the happy path, we have in mind the dangers that lay in wait just off the road for those who take the wrong turn. And we’re here to help you stay on the sunny side.A convenient tool for a developer who is focused on the happy path is to use a helpful programming construction called Panic.This post will explain why using Panic (and other similar error-handling syntax) can have devastating security impacts.<h2>What Is a Panic?&nbsp;</h2>Developers can run into a wide variety of errors while developing. Part of creating robust and healthy software is writing code to handle these errors in a graceful way. This means that when errors occur, the program will make a note of it and inform the user or developer of the issue. If appropriate, the code will continue executing its logic even after encountering an error.However, sometimes we find ourselves in a hurry. We want to focus on creating interesting features and solving complex problems. Thinking about all the ways the code might go wrong is a distracting irritation. For times like these, there’s panic.Panic is a construction used in Go and Rust to handle errors. It’s a powerful tool that can be a great help while debugging. When a panic is triggered, the program will crash immediately. Rather than print a helpful error message, the program will instead <a target="_blank" rel="noopener noreferrer nofollow" href="https://en.wikipedia.org/wiki/Halt_and_Catch_Fire_(computing)">halt and catch fire.</a><h2>What Does a Panic Look Like In Code?</h2>The easiest way to spot a panic is simply by looking for the word “panic”.<h3>Go Panics</h3>Go panics look like this:<pre><code>go
panic(“Error!”)</code></pre>However, there are more subtle cases where panics can be triggered by developers.Some Go methods will issue a panic in certain cases. For example, a logging function <code>log.Panic</code> will result in a panic. Other functions will contain the word <code>Must</code> which will panic if they run into an error case. This is a common convention in many <code>Go</code> standard packages as well as in the Cosmos SDK.<h3>Rust Panics</h3>Rust panics look like this:<pre><code>panic!(“Error!”);</code></pre>In Rust, there are many other macros in addition to <code>panic!</code> which will also result in a <code>panic</code>.&nbsp;These include:<pre><code>unreachable!
unimplemented!
assert_eq!
debug_assert_eq!
debug_assert_ne!
todo!</code></pre>Each of these macros can signal something different in terms of error-handling. For example, using <code>todo!</code> or <code>unimplemented!</code> communicates that a feature simply does not exist yet rather than indicating an error condition. However, while these macros mean something different to a human reading them, under the hood they will all issue a panic.Rust also includes methods for error-handling including <code>.unwrap()</code> and <code>.expect()</code>. These methods are used when calling a function.In Rust, functions can return <code>Result</code> types. A Result “wraps” other types. When everything is going well, a Result will contain the expected return value of the function, which will have a type like <code>str</code>&nbsp; for a string. On the other hand, when an error is triggered, the Result will wrap an error type, <code>Err</code>. When the calling code receives the value, it can “unwrap” the Result type to get the value the function returned, either something like <code>str</code> or an error <code>Err</code>. A Rust developer will write different conditional statements to handle all the expected types or variants of <code>Err</code> that a function can return.The <code>.unwrap</code> method is a shortcut that a developer can take instead of writing all the conditional statements. It will unwrap the Result and panic if it gets an <code>Err</code> type. The <code>.expect()</code> method behaves the same way and also allows the developer to print a custom message when the code panics.<h2>When to Panic</h2>When prototyping code, using panic as a placeholder for error-handling can save time.It can be distracting and time-consuming to create robust error-handling for every single edge-case when you’re just getting started with a new project.A panic will return a stack trace containing a lot of information about the error involved, including a stack trace and locations of relevant code on the file system. This is helpful for tracking down errors.Panics also occur accidentally, like when a process runs out of memory, overflows the stack, performs a division using 0, and so on. Depending on the context, these kinds of issues can be considered to be unrecoverable errors. In other words, something has gone terribly wrong. In this case, the best course of action is to stop execution, and a panic is an appropriate way to do so.<h2>When Not to Panic</h2>The power of panic also results in risks. For this reason, it should not be used in software in a production environment.Stack traces can aid an attacker in crafting an exploit. They also provide information about the underlying file system that can be used as part of sophisticated attacks that chain multiple small pieces of information together into a dangerous hack. If a panic can be predictably triggered in a piece of software, this on its own can be enough to perform a denial-of-service (DoS) attack.This is true for all software. However, the problem with using panics in production can be much&nbsp;than an information leak or temporary reduction in service availability due to DoS.&nbsp;In blockchain software in particular, the use of panic can have devastating consequences. This is because a crashing program may affect not only the availability of a service, but also the integrity of the state. In other words, a panic may cost you, literally.This is a concern for any projects using Go and Rust in their software stack. This includes projects that use either of these languages for development of applications or chains.&nbsp;For example, Cosmos applications are written in Go and Solana programs are written in Rust. It can also affect other chains that use Go or Rust for their node software, such as go-ethereum or Lighthouse.<h2>Example: Effects of a Panic in a Cosmos Project</h2>To better understand the impacts of panicking code in the context of blockchains, let’s explore an example in Cosmos.In the Cosmos ecosystem, it is possible to create code that runs automatically on a per-block basis. This is done via the <a target="_blank" rel="noopener noreferrer nofollow" href="https://docs.cosmos.network/master/building-modules/beginblock-endblock.html">BeginBlocker and EndBlocker methods</a> within a given module. As the documentation notes, it is possible to cause major slowdowns or even a chain halt if these functions aren’t used carefully.This can open up a path for an attacker. If user-controlled data can trigger a panic and that panic occurs in the context of code that handles consensus, the attacker could cause major issues. The validators will try to run code that panics, and from there will be unable to coordinate the state of the chain. This could halt the entire chain!&nbsp;More subtle side effects could occur as well. An attacker might be able to crash some validators, but not others. If there are a reduced number of validators active, this makes it easier to, for example, create a malicious governance proposal and have it pass. Reducing the number of validators on the network means that it’s relatively easy to win a voting process that has negative effects for the chain.This could lead to changes in a governance vote and allow a malicious subset of validators to take over the network!As security experts, naturally our minds go to scenarios where there is a malicious actor involved. But problems can arise even without an attacker involved. If the code can reach a state where it panics ‘on its own’&nbsp; – that is, without the panic being caused by user-controlled data – an issue like a chain halt could still occur.<h2>Handling Errors the Right Way</h2>In the example above, we can use <a target="_blank" rel="noopener noreferrer nofollow" href="https://docs.cosmos.network/main/building-modules/errors.html">Cosmos custom errors</a> instead of panics.The Cosmos SDK also allows you to configure ‘invariants’ which are statements that should always be true within a protocol. As an example, a user’s supply of a Token should never be greater than the total supply of that token. Rather than use a panic, invariants can be defined and handled gracefully.Defining invariants allows you to make use of <a target="_blank" rel="noopener noreferrer nofollow" href="https://github.com/cosmos/cosmos-sdk/blob/main/docs/core/simulation.md">simulations</a>, a Cosmos feature that allows for&nbsp;built-in <a target="_blank" rel="noopener noreferrer nofollow" href="https://halborn.com/what-is-fuzz-testing-fuzzing/">fuzz testing</a>. You can run these simulations during development and catch edge-cases before you ship.In general, regardless of what language or ecosystem you use, always make sure that error conditions are checked and properly handled.If using a panic is truly necessary in the case of an unrecoverable error, think carefully about how this may affect consensus operations. Evaluate whether an attacker could trigger a panic predictably and what side effects this may have.Paying close attention to the potential error-states of the program and handling them carefully is an essential practice. Error-handling is not the most exciting task as a developer; on the other hand, a lack of robust error-handling may make for a very exciting day for an attacker. It’s always worth the time and effort to think carefully about how code might behave given unusual inputs, and to handle those scenarios sooner rather than later.If your company is having trouble debugging, testing or overall just trying to make your protocol more secure and want professional security advice, connect with our Web3 security experts at <a target="_blank" rel="noopener noreferrer nofollow" href="mailto:halborn@protonmail.com">halborn@protonmail.com</a>.

Panic-Blockchain-Hacks.jpg

Halborn security engineer John Saigle explains why using Panic (& other similar error-handling syntax) can have devastating security impacts.

// Blog

John Saigle

Articles