![]() There are two different approaches to resolve this bug: Instead, they rely on the caller to configure the decoder with isSolid=false before the first item is decoded.Īs we have seen, this does not turn out very well. In essence, the bug is that the decoder classes do not guarantee that their state is correctly initialized before they are Recall that the code relies heavily on the soundness of the model’s state, which can now be violated easily. ![]() ![]() The PPMd state discussed in my previous post.Arrays with indices that are used to index into other arrays, for both reading and writing values.Than the actual buffer, allowing a heap-based buffer overflow. These variables may now hold a size that is larger Member variables holding the size of heap-based buffers.However, various parts of the uninitialized state can be used to cause memory corruptions: Then, for the second item, a new Rar2 decoder object is createdĪnd (since the solid flag is set) the decoding is run with a large part of the decoder’s state being uninitialized.Īt first sight, this may not look too bad. The first item will cause the solidStart flag to be set to false. The second item uses encoding method v2 (or v3), and has the solid bit set.The first item uses encoding method v1.We can easily violate this assumption with a RAR archive that is constructed as follows 2: That the first call on the decoder is with isSolid=false. Reinitialized for non-solid items anyway and the implicit assumption is that the caller of the decoder would make sure The constructors of these decoder objects leave a large part of their state uninitialized. In particular, for each of these three encoding methods there is a different decoder object. That seems to be correct, right? Well, the problem is that RAR supports three different encoding methods (excluding version 5), andĮach item can be encoded with a different method. Is configured with isSolid=false for the first item that is decoded.įurthermore, the decoder will (re)initialize its state (before starting to decode) whenever it is called with isSolid=false. The basic idea is to have a boolean flag solidStart, which is initialized to true (before the loop), making sure that the decoder RINOK(compressSetDecoderProperties ->SetDecoderProperties2( &isSolid, 1)) In this loop, we can find the following code:īyte isSolid = (Byte)((IsSolid(index) || item.IsSplitBefore()) ? 1 : 0) That contains a loop which iterates with a variable index over all items. The RAR handler has a method NArchive::NRar::CHandler::Extract 1 Let us have a look at how this is implemented in 7-Zip. Obviously, one needs to make sure that the decoder object initializes its state at the beginning (for the first item it is decoding). The idea is that if an item is decoded that has this solid bit set, the decoder would not reinitialize its state,Įssentially continuing from the state of the previous item. In the RAR format (before version 5), solid compression can be used in a very flexible way:Įach item (representing a file) of the archive can be marked as solid, independently from all other items. In particular if there are many files that are somewhat similar. This can yield a higher compression rate, Interpret them as the concatenation to one single data block, and then compress this whole block (as opposed to compressing every file for itself). The idea of solid compression is simple: Given a set of files (e.g., from a folder), we can This new bug arises in the context of handling solid compression. Then, we will take a brief look at 7-Zip’s patch.įinally, we will see how the bug can be exploited for remote code execution. In the following, I will outline the bug in more detail. Surprisingly, it is anything but harmless. Now you may think that this sounds harmless and boring.Īdmittedly, this is what I thought when I first discovered the bug. Into the decoder, causing usage of uninitialized memory. Unfortunately, the RAR handler fails to sanitize its input data and passes the incorrect configuration The initialization of some member data structures of the RAR decoder classes relies on the RAR handler to configure the decoder Very abstractly, the bug can be described as follows: Therefore, it is hardly surprising that any changes to this code are likely to introduce new bugs. Introductionħ-Zip’s RAR code is mostly based on a recent UnRAR version, but especially the higher-level partsĪs we have seen in some of my earlier blog posts, the UnRAR code is very fragile. UPDATE (): The antivirus vendor I was talking about was F-Secure. ![]() Since the antivirus vendor has not yet published a patch, I will add the name of the affected product inĪn update to this post as soon as this happens. (as the last two bugs) turned out to affect 7-Zip as well. I continued to spend time on analyzing antivirus software.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |