Vulnerability disclosure: remote code execution in Scripting Plugin

A new version of the Scripting DC Plugin has been released today fixing a serious vulnerability that allows attackers to remotely execute any code in the host system running any DC client compatible with DC Plugins, such as DC++. The nature of this vulnerability can cause various security issues, for example it makes the attacker possible to aquire any files from the host’s mounted filesystems.

For successful exploitation, Scripting Plugin version 1.0 should be installed AND enabled in any DC client / versions that support DC Plugins. DC clients having this particular plugin not installed (or installed but as long as the plugin is in disabled state) are NOT vulnerable.

For users running Scripting Plugin version 1.0 it is highly recommended to upgrade to version 1.10 as soon as possible to get protected from this vulnerability.

Please note that a vulnerable function named LuaExec has been completly removed from the plugin’s scripting API and that this release also updates the internal Lua engine to the latest version, both of which changes may cause incompatibilities with existing customly created Lua user scripts.

We’d like to thank RoLex of Team Elite for reporting, sharing proof of concept and recommending fixes for this issue.

DC++ 0.868+1 will require TLS 1.2 or TLS 1.3

In accordance with the published plan, the next DC++ release will increase the minimum supported TLS version from 1.0 to 1.2. This follows Firefox, Chrome, and Fedora doing so as well. As DC++ 0.868 supports TLS 1.3, DC++ will, for ADCS, use only TLS 1.2 or TLS 1.3. Additionally, client-client connections for ADC hubs will default to requiring TLS, also 1.2 or 1.3.

Widely used, currently maintained DC clients interoperably (Russian original) support TLS 1.3 in this manner as part of ADCS, as Delion’s post documents, including DC++ since version 0.868, ApexDC++ since version 1.6.5, AirDC++ since version 3.53, EiskaltDC++ since version 2.2.10, FlylinkDC++ since build 21972, and ncdc.

This DC++ release will, due to practical and efficient chosen-prefix SHA-1 collisions, similarly disallow SHA-1-based TLS ciphersuites. Remaining ciphersuites provide forward secrecy.

Finally, enforcing Diffie-Hellman keys of at least 2048 bits avoids the previous 1024-bit DH keys vulnerable to well-funded actors, and likely already broken by nation-states to which ADCH++ had defaulted.

Dropping less secure TLS versions 1.0 and 1.1, along with SHA-1-based ciphersuites and weak DH keys, protects DC++’s and the DC network’s security against current and emerging cryptographic attacks.

DC++ 0.868 is out and marked as stable

A year after the previous version, DC++ 0.868 is now available with various library updates (notably OpenSSL 1.1.1 with TLS 1.3 support) and a revised selection of public hub lists.

The list of public hubs came with the client has been pretty much outdated for some time. A few previously listed servers are already defunct while some are changed their web addresses. Therefore a refreshed list of secure and working hublist servers was long overdue. Many of such new public hublists will get auto-added to your collection upon the update to version 0.868 due to a change of policy regarding hublist server defaults. In the past a change of default hublist servers were not reflected in the actual settings – you had to remove  all existing server entries manually to get the updated defaults. This method, being deemed a bit cumbersome, has changed; in this release the addition will happen automatically and it will be the same in case of any future changes as well. A “Reset hub lists” button is also available in the settings should you want to quickly clean up the list of servers and get back to the defaults.

With the OpenSSL library update, DC++ 0.868 introduces support for TLS version 1.3 and is automatically preferring this newest secure communication standard when connecting to other DC clients and hubs. Backwards compatibility to the earlier versions of the protocol is decided to be maintained, similarly to most of the modern popular web browser software, until at least 2020.

Above the aforemntioned feature updates this is a maintanence release, with a few small updates here and there. There’s also a feature removal: support for the long defunct (and often criticised) Coral CDN network ended with this version.

Due to the useful features and security related fixes an immediate upgrade from earlier versions of DC++ is highly recommended.

 

DC++ 0.867 is out – Vulnerability disclosure

DC++ 0.867 has been released and also marked as the stable release. It fixes a serious remotely exploitable vulnerability that would crash the client if a malicious attacker sends trivially compilable malformed search result messages.

The victim should not need to initiate searches and the attacker should not need to be logged on to a hub for a successful exploitation altough the obvious place for finding victims and collecting attack surface information are the DC hubs.

Clients configured to a working active connectivity mode are the easiest targets, especially when logged in to any kind of Direct Connect hubs. Theoretically exploits can be created for clients running in passive mode, too, using possible additional weaknesses in various hub software.

The vulnerability seems to be exist as far back as in version 0.671 (released in 2005) and in all newer releases up to DC++ 0.866. Many other DC clients based on dclib, the core library of DC++ and released over the last 12 years should be vulnerable, too.

The vulnerability report and detalis are now publicly available in the DC++ bug tracker. Updating and using the newest, most secure DC clients has never been more important so the best everyone can do is to head over the DC++ download page and upgrade as soon as possible.

XML parsing of file lists

Many DC clients (and other software) have their own XML parser for parsing XML files and content. This means the parsers can be heavily specialized for performance (in the case of large file lists for instance) compared to just using a “standard parser” (i.e. one that has been used in multiple projects). However, building one’s own parser also means that the parser may be incorrect to a far greater extent, thereby increasing the risk that a malicious party (e.g. the one sending the file list) may try to remotely crash the receiver by sending incorrect files. Beyond the obvious concern for network security, clients may incorrectly allow files to be read or read incorrect data within those files.

I have compiled a list of potential errors that a file list may have, and generated file lists for each of those occurences. These file lists were then opened in DC++ (0.851) and verified to see what happened. This test should likely be done with all clients that don’t derive their own XML parsing with DC++’s (i.e., all DC++-mods will likely follow the below pattern).

I created multiple file lists (downloadable here), based on this file, generated with this C# snippet. Here are the results (Microsoft Office Excel file).

A summary of the results;

• DC++ will parse invalid data (e.g. omission of data) and sometimes replace the faulty data with “something sensible”, although this is almost in all cases wrong.
• In most cases where it is an invalid XML document, DC++ will ignore those sections or ignore the file altogether (this is good).
• DC++ will not crash on invalid data.

Most of the issues found can be solved by performing a XML-sanitation check before reading the document, by validating against the XSD. DC++’s XML parser does not have any XSD validation, so it couldn’t be done at this point anyway, but should such a validation be implemented, it will cause a (small or big depends on the source file list) performance hit.

While I didn’t test it, parsing of the XML list for version.xml and any hublists will likely have the same issue(s) as mentioned above. At least we won’t crash DC++.

If someone has other software that they can test this with, please feel free to do so and let me know so I can update the Excel sheet. It’s also possible that the resulting files are named incorrectly (e.g. by not requiring a CID in the file name), so just run the snippet code.

(Note: The files in this post may have a file name such as “foo-zip.pdf”, and it is because the file is actually a zip file but this blog software couldn’t handle that, so just change the file-extension to the appropriate one.)

Addressing DC++’s service provider, SourceForge

There has been a lot of discussion regarding changes to SourceForge’s hosting practices [1][2][3]. There are two things that SourceForge have done; created an opt-in “revenue program” and begun taking over old or non-updating (or even non-existant) projects.

The opt-in program is DevShare and allow developers (project administrators) to receive revenue based on modified installers. FileZilla is one of the major projects that have done so. The modified installers embed additional programs, thereby acting as ad services. The developers can choose which type of ads/programs are suggested, although they cannot say exactly which may or may not show up. The developers do nothing extra to accomodate this feature. The difference, as noted by Ghacks.net is that SourceForge will change the appearance of the download page to highlight the ad-specific one whilst still having a link to the other one (albiet not as easy to see).

The DC++ administrators were sent an e-mail from SourceForge regarding the DevShare program whether DC++ should or should not also opt-in for the DevShare program. The DC++ administrators declined this offer as the additional revenue was not needed for any basic operation and it felt it might violate the integrety of the installers. This was just as the DevShare program had been announced. No further action for this has been taken and no additional requests from SourceForge have been made.

The second part of SourceForge’s changes are that of modifications to old projects or completely taking over the projects (or even creating them in the first place). This can be seen with e.g. GIMP. As long as DC++ does not become stale or otherwise non-active this will never affect DC++.

All of this have caused us (the developers of DC++) to review our stance with SourceForge. Some facts before I continue:

• SourceForge have hosted DC++ (and other DC related software) since its inception (i.e. for several years) without any problems in this area.
• SourceForge provides stable code repositories and website resources. Although the speed of SourceForge network may be questionable, it is able to withstand hard DDoS:ing.
• DC++ hosts the source code repository, file downloads and website resources on SourceForge.
• There are other DC related projects that are also hosted on SourceForge.
• DC++ is considered a “valued projects” in that it has appeared on SourceForge’s project of the month as well as the DevShare offer. DC++ is also among the high-download projects at SourceForge.
• DC++ will not be directly affected by DevShare as we have not accepted such an offer. (I must stress it is an opt-in offer.)
• DC++ will not be directly affected by the abondoned projects changes as DC++ continue to be updated and will not qualify for such a change.
• At least one browser plugin, uBlock, have started to block SourceForge as a whole, thereby potentially restricting users from accessing DC(++) resources.

So, in light of all of this, we have begun to look into other project repositories:

• Launchpad – Already hosts other features for DC++, such as the bug tracker, but does not provide a sufficient code repository (Bazaar is near-dead), somewhat cumbersome download capabilities and no true website support.
• Github – No real website support. This is more suited for just the code repository than a full-on project repository. We are more likely to host the source code on Github and proxy that through another service.
• Bitbucket – Restricts number of contributors, no website support. poy suggests strongly that we do not move to Bitbucket.
• Google Code – Recently closed registration of new projects. (Lacked anyway certain features.)

There are other project repositories available, although no one of us have experience with most of them.

It is important for us to move forward with this, so here is our plan forward:

• Move (or at least parts of) source code repositories, websites and download facilities to our own hosting facilities. E.g., Rhodecode is being set up to address this for source code.
• DC++ will continue to use SourceForge as a minimum as its backup service provider. It is important to note that we have had a relatively pleasant experience with SourceForge – as project administrators.
• We will continue to monitor any further development in SourceForge management and changes.

We welcome suggestions, both from SourceForge and others, in how we can move forward.

DC++ 0.851

A new security & stability update of DC++ has been released today.

There are no user visible new features this time; besides the latest OpenSSL security fixes and hardening secure connection further by disallowing weak ciphersuites this DC++ version largely focuses on mitigating malicious situations where DC++ can be used for distributed denial of service (DDoS) attacks when beeing logged in to certain malevolent NMDC hubs.

Please note that most, if not all previous DC++ versions are affected of this problem therefore this release is highly recommended for everyone still using any older DC++ versions. Once all maintained NMDC hub software implements the mitigation for this problem it is highly probable that many existing hubs will require this DC++ release as the minimum version to use.

If no critical issues found, DC++ 0.851 should be marked as the new stable DC++ release within a short period of time.

For the complete list of changes in version 0.851, please explore the changelog.

DC++ 0.850

The first new DC++ release in the last nine months, version 0.850 fixes and hardens security related functions further notably to avoid all popular TLS exploits emerged since last April.

This release also contains stability and performance updates of various 3rd party libraries and improvements of the latest version of the compiler.

For complete list of fixes and upgraded libraries, please explore the changelog items and the linked bug discussions.

DC++ 0.842

The first stable release of the 0.840 series of DC++ is out. Besides a few SSL encryption related and stability fixes this version largely focuses on implementing various features asked for or recommended by the user community through our feature tracker.

The changelog shows all the implemented new features and fixes.

DC++ 0.842 also provides protection against the infamous “Heartbleed” OpenSSL vulnerability. This security hole has existed in DC++ since version 0.799.

There’s a high chance of version 0.842 is the last mainstream DC++ release that supports Windows XP.  Due to the still large userbase of the already unsupported operating system, security and major stability fixes are possible for a few more months using a separate branch targeting XP only. The update reminder system is modified so in case of any forthcoming version targeting Vista and later being released, XP users won’t see the notification dialog anymore.

From that time on people running Windows XP will see the update nag dialog only if there’s an update targeting their old OS. However, starting with version 0.840 every XP user gets a special reminder at startup about the EOS of DC++ in their operating system.

Due to the nice new features and security fixes the upgrade is highly recommended.

DC++ 0.831

A new bug fixing service release of DC++ has been released today fixing the following problems introduced with version 0.830:

• One of the bugs, marked as critical, prevents DC++ to respond to TTH searches on NMDC hubs.
• A problem with too small protocol command size limits can cause problems for hubs sending large user commands.
• The newly introduced direct encrypted private message channels are getting disconnected after some idle time.

All the fixed problems exist in version 0.830 only thus older versions are not affected. For users running DC++ 0.830 the upgrade is highly recommended.