CVE-2023-43621: security - croc: multiple issues in file sharing utility

• Products
  • Openwall GNU/*/Linux server OS
  • Linux Kernel Runtime Guard
  • John the Ripper password cracker
    • Free & Open Source for any platform
    • in the cloud
    • Pro for Linux
    • Pro for macOS
  • Wordlists for password cracking
  • passwdqc policy enforcement
    • Free & Open Source for Unix
    • Pro for Windows (Active Directory)
  • yescrypt KDF & password hashing
  • yespower Proof-of-Work (PoW)
  • crypt_blowfish password hashing
  • phpass ditto in PHP
  • tcb better password shadowing
  • Pluggable Authentication Modules
  • scanlogd port scan detector
  • popa3d tiny POP3 daemon
  • blists web interface to mailing lists
  • msulogin single user mode login
  • php_mt_seed mt_rand() cracker
• Services
• Publications
  • Articles
  • Presentations
• Resources
  • Mailing lists
  • Community wiki
  • Source code repositories (GitHub)
  • Source code repositories (CVSweb)
  • File archive & mirrors
  • How to verify digital signatures
  • OVE IDs
• What’s new

[<prev] [next>] [day] [month] [year] [list]

Date: Fri, 8 Sep 2023 15:37:55 +0200 From: Matthias Gerstner <mgerstner@…e.de> To: oss-security@…ts.openwall.com Subject: croc: multiple issues in file sharing utility

Hello list,

this report is about the Croc [1] file sharing utility. I have found a couple of security relevant issues in it that are not currently fixed. The upstream author doesn’t have enough resources to address them on its own and wants to develop fixes in the open. Therefore I have created GitHub issues in the upstream project and publish the full report today.

Only after finishing the review I found an older report [2] about Croc that states some of the same issues as in this report. These have been discovered independently of each other.

1. Review Scope and Motivation ==============================

This report is based on Croc release 9.6.5 (v9.6.5 Git repository tag). Croc is a cross platform tool. I reviewed it with a focus on the Linux operating system.

Croc was added to openSUSE Tumbleweed a while ago and the package’s description caught my interest due to its promise to "easily and securely send files from one computer to another". I found issues in similar tools before like KDE Connect [3] or Warpinator [4].

2. Introduction ===============

Croc is a command line program that is supposed to allow secure and easy file transfer between computers. It connects two parties, the sender and the receiver of files, over an untrusted network. Sender and receiver establish a shared secret that needs to be exchanged over a second channel, which is not covered by Croc.

Croc offers to automatically generate the shared secret in the style of a human readable phrase like:

 1355-sunday-yoga-africa

Alternatively the sender can also specify a custom free form shared secret that needs to have a minimum length of six characters.

2.1) Design Overview

Croc is a surprisingly complex utility, therefore this section offers a broader overview of how it works, to make clearer some of the later sections of the report.

The communication between sender and receiver is always routed through what is called a relay instance of Croc. There exists a default public relay reachable on the Internet, which is used if nothing else is configured. Users can also host their own relay. If no explicit IP addresses are configured then the sender also runs a relay implicitly and communicates its presence via a zeroconf protocol. This implicit relay on the sender side is prefered by the receiver, if possible (i.e. if firewalls are not preventing this).

While a relay can have its own password protection (`–pass` command line switch), there is a password “pass123” used by default i.e. relays will typically be accessible by anybody without authentication.

The initial connection to a relay happens via TCP on the default port 9009. The protocol used here allows some unencrypted operations, like sending a “ping” message for testing the availablity of the service. For regular operation a PAKE (password authenticated) key exchange is performed based on a custom implementation for Croc. When this succeeds then a relay encryption context is available and encrypted messages can be exchanged between sender and relay, or receiver and relay, respectively. No authenticity checks are present at this stage i.e. the relay could also be a man-in-the-middle or otherwise harmful.

The relay maintains “rooms” which are identifiers used for connecting pairs of sender and receiver that are interested to transfer files. Rooms are identified by a free form string. Sender and receiver communicate their desired room ID using their relay encryption context, i.e. the room IDs cannot be eavesdropped by other parties. On the sender/receiver side the room names are selected from the three character prefix of the shared secret. Once sender and receiver enter the same room at the relay, the relay switches into a “pipe” mode where it simply forwards all data between sender and receiver (full duplex) and no longer interprets the message contents.

At this stage sender and receiver can communicate with each other and will perform another PAKE key exchange. If this succeeds then a second sender/receiver encryption context has been established. The encrypted communication can only take place if the shared secret matches. So on this level a sort of authenticity check between sender and receiver can be assumed, provided that the secret has been shared in a safe manner. Also the relay should not be able to access the cleartext of the data exchanged between sender and receiver. Thus the authenticity of the relay should not be relevant at this point regarding safety of integrity of the transferred data.

Using the second level end to end encryption, the sender now tells the receiver which kind of files are about to be transferred (metadata). The receiver will ask the interactive user whether to accept the files. Then the files (which can also be directories or symlinks) specified by the sender will be created locally and the data received will be written to them. There is also support for transferring multiple files in ZIP files which will be decompressed transparently by the receiver. There is a file overwrite check in place for overwrite situations. The interactive user will be asked whether overwriting should take place or not.

For the actual file paylaod transmission a file chunk algorithm is employed and the transfer is potentially carried out over multiple TCP connections by connecting to a sequence of ports available at the relay (ports 9010 to 9013 by default). For these additional TCP connections further PAKE encryption contexts will be setup, based on the shared secret.

3. Security Relevant Findings =============================

3.1) Possible (Concealed) Creation of Files in Dangerous Path Locations

If more than one file is transferred via Croc then, before the transfer starts, the receiver only sees a summary line about the files about to be received, like:

Accept 2 files (159 B)? (Y/n)

Only after confirming this dialog the full file reception list will be printed, like:

Receiving (<-\[ip\]:\[port\])
file1 100% |████████████████████| (140/140 B, 610 B/s) 1/2
file2 100% |████████████████████| ( 0/ 1 B) 2/2

The Croc protocol allows the sender to specify arbitrary paths to be transferred. Via social engineering an attacker could attempt to transfer one or more malicious files in a larger file list, that otherwise looks unsuspicious.

There is a file overwrite check in Croc that prevents existing files from being overwritten without user consent (at least by default, there’s the `–overwrite` switch to disable the prompt). For not yet existing files there are no security boundaries though. So if e.g. `$HOME/.ssh/authorized_keys` is not existing yet on the receiver side, then the sender can transfer this, maybe unnoticed by the receiver. Even if the receiver notices it after the fact, it might be too late, and the attacker already had the chance to compromise the receiver’s system.

Two relevant pieces of information might be missing for an attacker in this scenario: the receiver’s home directory location and its current working directory. Guessing or determining the receiver’s home directory path via social engineering might be well within reach though. Simply implying that the CWD is the home directory might otherwise be a good guess. Also relative paths like `…/.ssh/authorized_keys` can be transferred. An attacker has to be careful about this, though, because if the path reaches above the home directory, then “permission denied” errors will become visible on the receiver end, which are more likely to raise alarm.

Fixing this kind of attack scenario is difficult, when trying to parse incoming file paths and to detect dangerous situations in userspace. Especially since there is also the possibility of symlinks and Croc even explicitly supports the creation of symlinks in its protocol. In Warpinator [4] the developers ended up using isolation techniques to lock the receiver process side in a specific download directory.

Using mount namespaces (ideally an existing tool for creating a namespace jail) or Linux features like Landlock is probably the best solution for this problem. Since Croc is cross platform, implementing isolation can become a large effort though, since there are no shared APIs available for this.

3.2) Circumventing the Interactive File Overwrite Prompt

As mentioned in issue 3.1) there is a check on the receiver side of Croc whether an incoming file path will overwrite an existing file, and Croc will ask the user interactively whether it should be overwritten, if it already exists. This check works reasonably well, even if symlinks are involved. I did not look that deep into this though - due to the following finding I stopped spending time on finding further possible ways around the restriction. There might still linger attack surface in the parallelism of the chunk transfer (exploiting race conditions) or by aptly crafting the file metadata.

There is a loophole in conjunction with the transparent ZIP transfer option though (`croc send --zip`). The sender alone decides if something will be zipped or not (somewhat confusingly flagged by the `FileInfo.TempFile` flag).

The receiver will take whatever data has been transferred and will try to unzip it. This way even the overwrite check can be overcome, by placing creative paths into the ZIP archive. Even relative paths like `…/…/.ssh/authorized_keys` can be placed in the ZIP archive. The unzip operation will silently overwrite existing files.

When combined with issue 3.1) then a potential attacker has a lot of freedom to attempt to trick the receiving party into harming its system.

If an isolation technique as outlined in issue 3.1) is implemented, then the consequences of overwriting files should be less problematic - although it could still be surprising if previously downloaded files are overwritten with something else. As an additional protection measure only the receiver should decide whether ZIP files are handled, or not. Better controlling the unzip process to prevent overwrites would also be helpful. The safest approach would be to use a pristine empty directory for each new file transfer where nothing can be overwritten in the first place.

3.3) Escape Sequences in Filenames are not Filtered

Filenames on Linux can contain arbitrary characters except for the path separator '/’. Thus filenames can also contain possibly dangerous characters like ASCII control codes (newline, linefeed, etc.) or even complete ANSI/CSI terminal escape sequences.

On the Croc receiver side the filenames communicated by the sender side are accepted unfiltered and are also output on stdout during transmission. When the latter happens, the escape sequences are interpreted by the receiver’s terminal and can lead to colored text, moving the cursor around or - if an insecure terminal emulator setup [5] is used - even arbitrary code execution can be achieved.

In particular this issue is a nice addition to issues 3.1) and 3.2), since it allows to hide filenames of previously transmitted files on stdout, therefore making the attack less conspicuous. This is an example of how this can be done:

# this moves the cursor up one line and performs a carriage return, thus
# overwriting the previous line on the terminal
sender $ touch "\`echo -e '\\033\[1A\\rharmless'\`"
sender $ touch "evil"
sender $ croc send evil \*harmless
\[...\]

receiver $ croc <shared-secret>
receiver $ Accept 2 files (0 B)? (Y/n) Y

harmless 100% |████████████████████| ( 0/ 1 B) 2/2

An interactive user will only see the “harmless” file, probably not noticing that a file seems to be “missing” in the output.

To fix this Croc should filter filenames on the receiver side and either reject or replace any unsafe non-printable characters.

3.4) Use of Parts of the Shared Secret as Room Name

The leading three characters of the shared secret are implicitly used to select a common “room name” at the relay so that sender and receiver can find each other (croc.go:827, croc.go:769, croc.go:572, croc.go:483).

When using shared secrets generated by Croc this is fine, because they are formatted just so that the leading part of the secret will make up the room name, like in "1355-sunday-yoga-africa". The leading number is completely unrelated to the rest of the shared secret. For some reason only the leading three digits will be used for the room name, in this case "135", while the final “5” will remain unused.

If a sender is selecting a custom shared secret then things can look different, though. Imagine selecting a secret like "MySecretPass". Now the relay will get “MyS” as room name. The relay is a possibly untrusted party that is not verified in the Croc protocol scheme (except if a relay password (`–pass`) is explicitly used). The room name is visible in cleartext to the relay, though. In the example of this custom secret, the room name reveals information about the rest of the shared secret used by sender and receiver. A malicious relay might thus be able to guess the shared secret or the cryptography may be otherwise weakened, allowing the relay to eavesdrop on the ongoing communication, or to impersonate the receiver.

For the parallel file chunk transfer further room names of the form `<digest>-<port>` (croc.go:1174) are used for setting up connections on the relay transfer ports (`–ports` option). Here `<digest>` is the SHA256 digest of the five leading characters of the shared secret. So it would be the SHA256 digest of "1355-" or “MySec” in the examples above. Of the resulting digest only the leading six characters will be used for the room name. The relay might be able to make deductions about the relatively short five character input for the hash e.g. by building rainbow tables. Although there will be a lot of collisions that likely make a practical attack difficult, this feels risky overall.

To fix this sender and receiver should always use a (sufficiently cryptographically secure) digest of the shared secret as room name. Generally it should be avoided to use the shared secret for anything else than setting up the cryptography - any use beyond that should be carefully considered and a safely derived value should be used.

3.5) Unencrypted “ips?” Message

As a typical part of the Croc protocol (if no explicit `–ip` is passed), the receiver will ask the sender about its locally assigned IP addresses via the `ips?` message (croc.go:792). This message and its reply are sent unencrypted. I assume there is no encryption, because the receiver might still switch the connection to a direct one, without going through a public relay, and setting up the encryption context twice might add additional latency, or additional code complexity.

The message being unencrypted means, however, that the sender will send out cleartext information over the Internet, containing all locally assigned IP addresses. This might be an unexpected information leak for a range of users. It can reveal information about the structure of internal networks or otherwise offer information about the identity of the sender.

To fix this, the encryption layer should be established before any other data is transferred between sender and receiver.

3.6) Explicit Evaluation of Wildcard Characters on the Sender Side CLI

The Croc command line tool explicitly (re)evaluates wildcard glob characters in filename arguments (croc.go:262). This seems highly unusual to me, since normally the user’s shell will expand wildcards, not the programs that the filenames are passed to.

This means even if special characters are escaped on shell level, that Croc will still attempt to expand them. This only happens if a filename contains at least one `*` character. For a sender side user this could be surprising, if a filename actually contains an `*` character, that this will suddenly be expanded nevertheless. Although a bit far fetched it might still pose a social engineering attack vector, by tricking somebody into forwarding a strangely named file and make them unwittingly send more files than intended.

The principle of least surprise is violated here and I would drop this logic, or execute it only in whatever use case this is helpful with.

3.7) Well known “pingRoom” in Relays

This is not actually a security issue, since I couldn’t find anything harmful to do with it. Still this aspect allows a relay to operate in a confusing state that should better not occur in the first place.

For processing “ping” messages the relay uses a well known "pingRoom". However, a malicious sender can specify “pingRoom” also as an actual room name for transmitting files. First I thought this could be suitable for causing the relay to crash, by tricking it into deleting the "pingRoom". The relay actually attempts to do this, but the “pingRoom” is a global variable and not stored in the dynamic room map, thus nothing bad happens.

This “pingRoom” should be excluded from being used for actual file transfers. On a side topic I would generally restrict the length of room name to a short string. And maybe introduce a special namespace like rooms starting with a “.” that cannot be used for file transfers, to generalize this concept of special rooms.

3.8) Shared Secret Passed on Command Line

On the sender side a custom shared secret can be specified via the `croc send –code <SECRET>` command line. On the receiver side the shared secret, custom or not, is typically passed on the command line using the `croc <SECRET>` command line . The latter invocation variant is actively advocated by the output displayed on the sender side like:

On the other computer run

croc <SECRET>

By passing the shared secret on the command line it will become visible on the host’s process list for all local users (on Linux and most UNIX like systems). On a multi user system this might allow other local users to get knowledge of the shared secret and to receive the files instead of the intended recipient.

To fix this, the shared secret should be read from stdin, a local file or an environment variable, even though it will be less intuitive than passing it on the command line.

4. Cryptography ===============

I am not a cryptography expert, therefore I did not even start to analyze the formal security of the PAKE protocol implementation in Croc. Still I have made some higher level observations regarding the use of cryptography in Croc that are collected in this section.

4.1) Custom PAKE Protocol

The implementation of a custom PAKE protocol for this utility generally seems risky to me. The finding in [2] shows that problematic issues can linger here.

The use of the fixed `weakKey` (tcp.go:176) and why this is cryptographically secure should be well documented I believe.

4.2) Mixing of Encrypted and Unencrypted Messages

One aspect that I found problematic about the communication protocol in Croc is that encrypted and unencrypted messages are mixed on the same channel and there is no clear transition point as to when the channel is secured.

I would find it better if the channel would be secured right away, no matter what, and no unencrypted messages would be transmitted after that. There is one point after which unencrypted communication is rejected in croc.go:1233. This is at a relatively late stage of the protocol though.

4.3) The same Channel is used for Various Different Kinds of Contexts

Similarly I found it difficult to follow that the same TCP connection is potentially used for many different kind of contexts: unencrypted communication (towards the relay and later towards the peer), the encryption context setup with the relay and the encryption context setup with the peer. The shared secret is then also potentially reused on additional TCP ports on the port range used to transfer file chunks.

This mix of contexts is sometimes difficult to follow in the code, like the same functions are used for multiple contexts and the actual context is determined only by boolean flags.

I don’t know how to improve on this without major changes to the current protocol scheme, though. Maybe the code could at least be refactored to make the different contexts clearer.

4.4) Authenticity Completely Relies on the Shared Secret

An aspect that always makes we worry in programs like Croc, that don’t rely on a trusted party, is that the authenticity verification of the communication partner completely relies on a shared secret that somehow needs to be exchanged over a second channel.

I am missing some heads up in the Croc documentation that makes users aware how important a sufficiently safe exchange of the shared secret is for the safety of the application.

Maybe also adding an explicit peer authenticity verification step would make this clearer than just relying on the shared secret and making it work "like magic". A prompt in the spirit of what openSSH does for host authenticity verification.

4.5) Minimum Shared Secret Length can Lead to very short PAKE Password Input

For custom shared secrets the minimum length is currently set to six characters. When using such a short shared secret then, due to the use of the prefix of the shared secret as room names, `pake.InitCurve()` will only receive a single byte as password input e.g. in `croc.go:1112` and `croc.go:224`. A single byte of input seems critically low.

Requiring longer shared secrets could improve upon this. But also avoiding to use cleartext portions of the shared secret for other things would make it possible to use the full shared secret for the PAKE setup.

5. CVE Assignments ==================

I have requested CVEs from Mitre for the more tangible issues 3.1 through 3.5 and issue 3.8. I will publish them here once they are available.

6. Timeline ===========

2023-08-08: I started the review of the Croc codebase. 2023-08-31: I reported my findings to the upstream author and offered coorindated disclosure. He replied quickly and stated that he wants to address the issues publicly without a formal embargo. 2023-09-04: I replied and agreed to open issues in the GitHub upstream project. I asked about his wishes about CVE assignments, but did not get a reply anymore (yet). 2023-09-08: I created public GitHub issues corresponding to the findings in my report. I requested CVEs from Mitre for the more tangible issues found. I published the full report.

7. References =============

[1]: https://github.com/schollz/croc.git [2]: https://redrocket.club/posts/croc [3]: https://www.openwall.com/lists/oss-security/2020/10/13/4 [4]: https://www.openwall.com/lists/oss-security/2023/04/26/1 [5]: https://www.openwall.com/lists/oss-security/2017/05/01/13

– Matthias Gerstner <matthias.gerstner@…e.de> Security Engineer https://www.suse.com/security GPG Key ID: 0x14C405C971923553

SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.