{"id":3369,"date":"2014-12-05T18:45:56","date_gmt":"2014-12-05T17:45:56","guid":{"rendered":"http:\/\/glandium.org\/blog\/?p=3369"},"modified":"2014-12-05T18:45:56","modified_gmt":"2014-12-05T17:45:56","slug":"using-c-templates-to-prevent-some-classes-of-buffer-overflows","status":"publish","type":"post","link":"https:\/\/glandium.org\/blog\/?p=3369","title":{"rendered":"Using C++ templates to prevent some classes of buffer overflows"},"content":{"rendered":"

I recently found a small buffer overflow in Firefox's SOCKS support<\/a>, and came up with a nice-ish way to make it a C++ compilation error when it may happen with some template magic.<\/p>\n

A simplfied form of the problem looks like this:<\/p>\n

\n
class nsSOCKSSocketInfo {\r\npublic:\r\n    nsSOCKSSocketInfo() : mData(new uint8_t[BUFFER_SIZE]) , mDataLength(0) {}\r\n    ~nsSOCKSSocketInfo() { delete[] mData; }\r\n\r\n    void WriteUint8(uint8_t aValue) { mData[mDataLength++] = aValue; }\r\n\r\n    void WriteV5AuthRequest() {\r\n        mDataLength = 0;\r\n        WriteUint8(0x05);\r\n        WriteUint8(0x01);\r\n        WriteUint8(0x00);\r\n    }\r\nprivate:\r\n    uint8_t* mData;\r\n    uint32_t mDataLength;\r\n    static const size_t BUFFER_SIZE = 2;\r\n};\r\n<\/pre>\n<\/blockquote>\n
Here, the problem is more or less obvious: the third WriteUint8() call in WriteV5AuthRequest() will write beyond the allocated buffer size. (The real buffer size was much larger than that, and it was a different method overflowing, but you get the point)<\/p>\n
While growing the buffer size fixes the overflow, that doesn't do much to prevent a similar overflow from happening again if the code changes. That got me thinking that there has to be a way to do some compile-time checking of this. The resulting solution, at its core, looks like this:<\/p>\n
\n
template <size_t Size> class Buffer {\r\npublic:\r\n    Buffer() : mBuf(nullptr) , mLength(0) {}\r\n    Buffer(uint8_t* aBuf, size_t aLength=0) : mBuf(aBuf), mLength(aLength) {}\r\n\r\n    Buffer<Size - 1> WriteUint8(uint8_t aValue) {\r\n        static_assert(Size >= 1, \"Cannot write that much\");\r\n        *mBuf = aValue;\r\n        Buffer result(mBuf + 1, mLength + 1);\r\n        mBuf = nullptr;\r\n        mLength = 0;\r\n        return result;\r\n    }\r\n\r\n    size_t Written() { return mLength; }\r\nprivate:\r\n    uint8_t* mBuf;\r\n    size_t mLength;\r\n};\r\n<\/size><\/pre>\n<\/blockquote>\n
Then replacing WriteV5AuthRequest() with the following:<\/p>\n
\n
void WriteV5AuthRequest() {\r\n    mDataLength = Buffer<BUFFER_SIZE>(mData)\r\n        .WriteUint8(0x05)\r\n        .WriteUint8(0x01)\r\n        .WriteUint8(0x00)\r\n        .Written();\r\n}\r\n<\/pre>\n<\/blockquote>\n
So, how does this work? The Buffer class is templated by size. The first thing we do is to create an instance for the complete size of the buffer:<\/p>\n
Buffer<BUFFER_SIZE>(mData)<\/code><\/p><\/blockquote>\n
Then call the WriteUint8 method on that instance, to write the first byte:<\/p>\n
.WriteUint8(0x05)<\/code><\/p><\/blockquote>\n
The result of that call is a Buffer<BUFFER_SIZE - 1> (in our case, Buffer<1>) instance pointing to &mData[1] and recording that 1 byte has been written.
\nThen we call the WriteUint8 method on that result, to write the second byte:<\/p>\n
.WriteUint8(0x01)<\/code><\/p><\/blockquote>\n
The result of that call is a Buffer<BUFFER_SIZE - 2> (in our case, Buffer<0>) instance pointing to &mData[2] and recording that 2 bytes have been written so far.
\nThen we call the WriteUint8 method on that new result, to write the third byte:<\/p>\n
.WriteUint8(0x00)<\/code><\/p><\/blockquote>\n
But this time, the Size template parameter being 0, it doesn't match the Size >= 1<\/code> static assertion, and the build fails.
\nIf we modify BUFFER_SIZE<\/code> to 3, then the instance we run that last WriteUint8 call on is a Buffer<1> and we don't hit the static assertion.<\/p>\n
Interestingly, this also makes the compiler emit more efficient code than the original version.<\/p>\n
Check the full patch<\/a> for more about the complete solution.<\/p>\n","protected":false},"excerpt":{"rendered":"
I recently found a small buffer overflow in Firefox’s SOCKS support, and came up with a nice-ish way to make it a C++ compilation error when it may happen with some template magic. A simplfied form of the problem looks like this: class nsSOCKSSocketInfo { public: nsSOCKSSocketInfo() : mData(new uint8_t[BUFFER_SIZE]) , mDataLength(0) {} ~nsSOCKSSocketInfo() { […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[25],"tags":[23],"class_list":["post-3369","post","type-post","status-publish","format-standard","hentry","category-planet-mozilla","tag-en"],"_links":{"self":[{"href":"https:\/\/glandium.org\/blog\/index.php?rest_route=\/wp\/v2\/posts\/3369","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/glandium.org\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/glandium.org\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/glandium.org\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/glandium.org\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=3369"}],"version-history":[{"count":6,"href":"https:\/\/glandium.org\/blog\/index.php?rest_route=\/wp\/v2\/posts\/3369\/revisions"}],"predecessor-version":[{"id":3381,"href":"https:\/\/glandium.org\/blog\/index.php?rest_route=\/wp\/v2\/posts\/3369\/revisions\/3381"}],"wp:attachment":[{"href":"https:\/\/glandium.org\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=3369"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/glandium.org\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=3369"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/glandium.org\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=3369"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}