{"id":1167,"date":"2015-05-07T17:40:19","date_gmt":"2015-05-07T15:40:19","guid":{"rendered":"http:\/\/blog.rewolf.pl\/blog\/?p=1167"},"modified":"2015-07-10T16:11:15","modified_gmt":"2015-07-10T14:11:15","slug":"resolving-vmware-workstation-10-0-6-crash","status":"publish","type":"post","link":"http:\/\/blog.rewolf.pl\/blog\/?p=1167","title":{"rendered":"Resolving VMware Workstation 10.0.6 crash"},"content":{"rendered":"

Two days ago VMware <\/strong>published new update for Workstation <\/strong>version 10 <\/strong>(release notes<\/a>). According to the changelog it should fix some security issues reported in OpenSSL<\/strong>. That’s nice, however there is a small problem with this update. VMware.exe (the GUI part of VMmare) started crashing immediately after update. This was quite a learning experience, do not update critical software if you have something important to do, as the new version can be worse than the one you are using. Since I didn’t have the previous installer at hand, I had to somehow resolve this issue differently (yeah sure, I just wanted to debug it and see, why it is crashing).<\/p>\n

<\/p>\n

The crash on my machine is 100% repeatable, and it crashes on security cookie check inside libcurl.dll<\/strong>. As most of you know libcurl <\/strong>is an open source library, so the bug should be hidden somewhere inside libcurl <\/strong>source code, or in the additional\/changed code that guys from VMware possibly touched. In the latter case, there should be available modified source code of the libcurl <\/strong>on the VMware page. It is not the case this time, so (in theory) it is fault of the libcurl <\/strong>itself. Crash happens inside the function that seems to enumerate DNS servers. Libcurl <\/strong>can be compiled with many different options and can use many different third party libraries. VMware’s libcurl <\/strong>version is compiled with static version of zlib <\/strong>and c-ares<\/a><\/strong>, it is also dynamically linked with OpenSSL<\/strong>. It is worth to note which versions of mentioned libraries are used. Most of open source libraries includes version number inside compiled binaries so it is rather easy to gather those information:<\/p>\n\n\n\n\n\n
<\/td>\nVMWare 10.0.5<\/td>\nVMWare 10.0.6<\/td>\nCurrent version<\/td>\n<\/tr>\n
libcurl<\/td>\n7.19.5<\/td>\n7.24.0<\/td>\n7.42.1<\/td>\n<\/tr>\n
zlib<\/td>\n1.2.3<\/td>\n1.2.3<\/td>\n1.2.8<\/td>\n<\/tr>\n
c-ares<\/td>\n1.5.1<\/td>\n1.7.5<\/td>\n1.10.0<\/td>\n<\/tr>\n<\/table>\n

Particulary interesting for me was libcurl <\/strong>and c-ares<\/strong>, as zlib <\/strong>probably doesn’t enumerate DNSes :) I’ve tried to localize the crashing function inside the source code of mentioned libs, but I was missing one detail (obviously!). In the newest version of c-ares<\/strong>, the function similar to the one that is crashing VMware is named get_DNS_NetworkParams()<\/strong>. This function doesn’t crash and it looks fine. After a few minutes of looking at the code and wondering what’s wrong I realized that I’ve freshly cloned repository<\/a> with the latest changes and I should probably go back in time and check some older version. Fortunately c-ares<\/strong> repository is properly tagged with release version numbers (at least since version 1.7.0<\/strong>). After checking out proper revision I’ve easily identified crashing function: get_iphlpapi_dns_info()<\/strong>. Simplified code, just to show the problem:<\/p>\n

#define INET_ADDRSTRLEN  22\r\n\r\nint get_iphlpapi_dns_info(char *ret_buf, size_t ret_size)\r\n{\r\n\tconst size_t  ipv4_size = INET_ADDRSTRLEN + 1;  \/* +1 for ',' at end *\/\r\n\tsize_t        left = ret_size;\r\n\tchar         *ret = ret_buf;\r\n\t\/\/...\r\n\tfor (\/*...*\/)\r\n\t{\r\n\t\t\/\/...\r\n\t\tif (left > ipv4_size)\r\n\t\t{\r\n\t\t\tsome_function_that_fills_given_buffer(ret, ipv4_size - 1);\r\n\t\t\tsize_t stringlen = strlen(ret);\r\n\t\t\tret[stringlen] = ',';\r\n\t\t\tret[stringlen + 1] = '\\0';\r\n\t\t\tret += stringlen + 1;\r\n\t\t\tleft -= ret - ret_buf;\t\/\/ <- !!! BUG BUG !!!\r\n\t\t}\r\n\t\t\/\/...\r\n\t}\r\n\t\/\/...\r\n}\r\n\r\n\/\/...\r\n\t\/\/ function call\r\n\tchar buf[512];\r\n\tget_iphlpapi_dns_info(buf,sizeof(buf));\r\n\/\/...\r\n<\/pre>\n
Variable left<\/em><\/strong> should be updated on each iteration with the length of the written data, so it will always contain number of bytes left in the ret_buf<\/em><\/strong>. As you may already noticed, ret_buf<\/em><\/strong> doesn't change throughout the function, so left<\/em><\/strong> is updated with the length of all strings written since the first iteration. It goes below 0 very fast and since it is declared as size_t<\/strong> which is unsigned it will be interpreted as such in the if (left > ipv4_size)<\/em><\/strong> comparison and at the end it will overrun ret_buf<\/em><\/strong> (only if there is enough records to process by the for loop).<\/p>\n
Described bug was present in c-ares<\/strong> library since the very begining (2004-06-10<\/a>). There were some changes regarding IPv6<\/strong> (2011-05-17<\/a>) that were modifying this function, but bug persisted probably due to copy&paste from IPv4<\/strong> handler. Someone fixed this bug almost a year later (2012-02-25<\/a>) and the other person rewrote whole code few months later. Unfortunately VMware chose to use version 1.7.5<\/strong> which was released before this bug was fixed (2011-08-16<\/a>). Blast from the past.<\/p>\n
If you are experiencing crashes in VMware Workstation 10.0.6 just use libcurl.dll from the previous build, at least it will stop crashing.<\/strong><\/p>\n
UPDATE:<\/strong> Someone at VMware forum<\/a> pointed out that it is sufficient to get libcurl.dll<\/strong> from the \\OVFTool\\<\/strong> directory and it will solve the issue. Indeed it is true, as libcurl<\/strong> from mentioned directory uses c-ares<\/strong> version 1.9.1<\/strong> (libcurl<\/strong> itself is also newer as it has version 7.30.0<\/strong>).<\/p>\n
UPDATE 2 (2015-07-10): <\/strong>This issue was fixed with v10.0.7, libcurl was updated to v7.32.0. I've also received free copy of VMware Workstation v11. Thanks!:\"vmware_gift\"<\/p>\n","protected":false},"excerpt":{"rendered":"
Two days ago VMware published new update for Workstation version 10 (release notes). According to the changelog it should fix some security issues reported in OpenSSL. That’s nice, however there is a small problem with this update. VMware.exe (the GUI part of VMmare) started crashing immediately after update. This was quite a learning experience, do […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[10,3],"tags":[],"_links":{"self":[{"href":"http:\/\/blog.rewolf.pl\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1167"}],"collection":[{"href":"http:\/\/blog.rewolf.pl\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/blog.rewolf.pl\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/blog.rewolf.pl\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/blog.rewolf.pl\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1167"}],"version-history":[{"count":33,"href":"http:\/\/blog.rewolf.pl\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1167\/revisions"}],"predecessor-version":[{"id":1402,"href":"http:\/\/blog.rewolf.pl\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1167\/revisions\/1402"}],"wp:attachment":[{"href":"http:\/\/blog.rewolf.pl\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1167"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/blog.rewolf.pl\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1167"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/blog.rewolf.pl\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1167"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}