I create this issue to represent the call authentication security concerns written up at https://crysp.uwaterloo.ca/opinion/wire/ .

When securing a conversation, confidentiality (hiding the contents of the conversation) is not the only desirable property. Without also authenticating the conversation, an attacker located in the network (e.g., a malicious actor intercepting traffic on a user's LAN, or a compromised ISP) can insert themselves between the endpoints. Wire provides both properties for text-based conversations.

The Wire protocol uses SRTP to secure audio/video calls. SRTP requires an external mechanism to establish the initial cryptographic key to protect the data. Wire uses a DTLS handshake to establish this initial key. DTLS is a UDP-based analog of TLS (used to secure HTTPS web browsing). Consequently, the key exchange in a DTLS handshake needs to be authenticated by a certificate authority, as in the case of web certificates. Based on some quick packet captures, it appears that the certificates used by Wire for this DTLS handshake are self-signed. If this is truly the case, then the handshakes do not provide any authentication in the presence of an active network attacker (i.e., a network attacker that can modify traffic), making Wire audio/video calls vulnerable to man-in-the-middle attacks.

The Wire security whitepaper says that "the authenticity of the clients is also verified during the handshake", but this is not consistent with the use of self-signed DTLS certificates. If the certificates are authenticated by the central Wire servers, then this prevents call interception by anyone except for the Wire operators.

In either case, the use of DTLS here is highly unusual and the security it provides is sub-optimal. A better approach would be to use a protocol like ZRTP (the standard used by Signal, Jitsi, Linphone, and others) to establish the initial SRTP key, or perhaps a more advanced key exchange scheme. The authentication for this scheme should not be based on certificates (as in DTLS); instead, the authentication should be bound to the long-term keys that are used by Wire's text-based conversations. A very simple solution would be to transparently perform a well-known unauthenticated key exchange (e.g., Diffie-Hellman) over an authenticated Wire text conversation, and to use the resulting key to initiate SRTP for the audio/video call.

The Wire security whitepaper mentions that authenticating audio/video calls against the cryptographic identities used for the text messaging protocol is future work, so this issue appears to be known.

I just tried to build on linux x86 and got :
./prepare.sh
fatal: reference is not a tree: a7facf0cd496e8952e355e72af755686024567fc
Unable to checkout 'a7facf0cd496e8952e355e72af755686024567fc' in submodule path 'contrib/generic-message-proto'

Stack overflow seems to say this means that the generic-message-proto submodule references a local version that hasn't yet been pushed.

I create this issue to represent the codec size concerns written up at https://crysp.uwaterloo.ca/opinion/wire/ .

It has been known for some time (e.g., WMM06, WBMM07, and WMSM11) within the system security academic community that using variable-bitrate codecs within an encrypted tunnel leaks information about the communication. Since encryption does not hide the length of the messages being transmitted, the bitrate of a conversation over time can be observed by a passive network attacker, even without access to the encryption keys in use. In some cases, knowledge of the bitrate changes is sufficient to reconstruct the unencrypted conversation with high accuracy. Consequently, while variable-bitrate codecs use the available bandwidth more efficiently, using constant-bitrate codecs is important for security.

The security whitepaper mentions that Wire uses the Opus codec to transmit audio data. The whitepaper does not mention what codec is used for video data. Opus supports both variable- and constant-bitrate encodings, so it is unclear if Wire is vulnerable to traffic analysis. In any case, Wire should ensure that constant-bitrate codecs are used for both audio and video data, and that this is clearly stated in the security whitepaper.

This issue is mentioned at https://crysp.uwaterloo.ca/opinion/wire/ , a review of Wire by a security researcher.

The Wire client is open source—and open to analysis by security researchers—but the server software is not.

Notably, close-sourcing the server means that if anything happens to Wire Swiss, the ecosystem of Wire users dies with it. Nobody can spin up their own server and keep things running into the future. And of course, the server may have security vulnerabilities that nobody can safely check for, because the code is unavailable.

The code in this repository (version 3.4) is outdated and no longer API compatible to ZMessaging
https://github.com/wireapp/wire-android-sync-engine/tree/108.0 or later.

The current wireapp-android requires at least ZMessaging version 112, which requires API features only present in AVS version 3.6 or later.

native calls not present but required are, among others:
wcall_config_update()
wcall_create()
...

wireapp-android can be built against AVS version 3.4 but will crash at runtime when attempting to call these from ZMessaging

When i install in latest mac book which cpu is m1. I get this error when I start voice with other.
I had try two mac and this error both exist.

Hi I want to use this ,but I don't know how use . Do you have any develop document ?

Format String Vulnerability

There is a Format String vulnerability in sdp.cpp line 99.

https://github.com/wireapp/wire-audio-video-signaling/blob/6bd9e51730a80cf527f7f30d7f8d6853fb2d875d/src/peerflow/sdp.c#L99

The function parameter value of function sdp_media_set_lattr() is controllable by an attacker and can lead to a format string attack. The function sdp_media_set_lattr() is implemented in media.c of the library re.

The vulnerability is fixed in current Android and iOS Wire Applications.

The vulnerability was exploitable in the Android and iOS Wire Apps at least until Wire Android Version 3.46.890 and iOS Version 3.58. An attacker could crash remote Wire Applications by a call with malformed sdp data, if the remote particpant accepted the call. The vulnerability could potentially lead to remote code execution.

steven@stevens-MBP WireAVS % git submodule init
steven@stevens-MBP WireAVS % git submodule update
steven@stevens-MBP WireAVS % git submodule foreach git fetch
Entering 'contrib/cryptobox-c'
Entering 'contrib/generic-message-proto'
Entering 'contrib/googletest'
Entering 'contrib/rem'
Entering 'contrib/rew'
Entering 'contrib/sodium'

There is no contrib/re.
The contrib/re files are missing during final make command.
But I can git clone 're' manually into contrib folder and everything works fine.
Please fix the submodule config.

Hi，I'm using a locally built WebRTC, no headers.zip file is generated, only android.zip. please how can i solve it

in ./webrtc/script/version.sh it says m79 but the actual code requires higher version API that I can't compile it on m79 dependency.

I've had a glance at your code and it seems you're not handling the MSG_EOR flag which means you will treat incoming partial SCTP messages as whole messages, thus violating the message-oriented principle of SCTP (and data channels). This is a widespread issue in many implementations we're currently trying to clean up.

If you need help, you can look at the relevant section in RAWRTC's code or at Mozilla's implementation. I'm the author of RAWRTC and I've also worked on Mozilla's data channel code, so feel free to ping me if you have any questions.

Tracked (and resolved) for Firefox in bug 979417. For Chromium, this is tracked in issue 7774.

wire-audio-video-signaling-master\mediaengine\webrtc There is no file?

I am looking to get started with the AVS code base but I note the zcall command line utility which would have made a good stating point to understand how to work with the code appears to be missing from the repository. It is described in the README.md so I believe that this is something that should exist?

Hello, I want to integrate into my project, I hava turn/sturn server, but how can I use this library, does someone give an example code or document? Thanks a lot.

When in a group chat and a file is sent to the group, the following code snippet fails (400) to work:

        case GENERIC_MESSAGE__CONTENT_ASSET:
            struct Asset *asset;
            struct Asset__Original *ao;
            Asset__RemoteData *ar;
            asset = gm->asset;
            ao = asset->original;
            ar = asset->uploaded;

            engine_fetch_asset(zcall_engine, conv->id, ar->asset_id, "/tmp/");

Also, while in a group chat, calling engine_send_file using for example: engine_send_file(conv, "image/jpeg", "/tmp/x.jpg"); also fails (404).

make WEBRTC_VER=72.local dist_android
armv7 is ok:
[armeabi-v7a] Compile++ thumb: avs <= flow_manager.cc
[armeabi-v7a] Compile++ thumb: avs <= media_manager.cc
[armeabi-v7a] Compile++ thumb: avs <= video_renderer.cc
[armeabi-v7a] Compile++ thumb: avs <= audio_effect.cc
[armeabi-v7a] SharedLibrary : libavs.so
[armeabi-v7a] Install : libavs.so => libs/armeabi-v7a/libavs.so

But arm64 is failed:
......

/home/ryan/wire-audio-video-signaling/build/toolchains/android-arm64/ndk/ndk-build -C android -I ../build/android-arm64
Android NDK: WARNING: APP_PLATFORM android-21 is higher than android:minSdkVersion 1 in ./AndroidManifest.xml. NDK binaries will not be comptible with devices older than android-21. See https://android.googlesource.com/platform/ndk/+/master/docs/user/common_problems.md for more information.
Android NDK: WARNING:jni/Android.mk:avs: non-system libraries in linker flags: -lavscore -lre -lrew -lsodium -lwebrtc -lc++_static -lc++abi
Android NDK: This is likely to result in incorrect builds. Try using LOCAL_STATIC_LIBRARIES
Android NDK: or LOCAL_SHARED_LIBRARIES instead to list the library dependencies of the
Android NDK: current module

make[1]: Entering directory `/home/ryan/wire-audio-video-signaling/android'
[arm64-v8a] Compile++ : avs <= flow_manager.cc
[arm64-v8a] Compile++ : avs <= media_manager.cc
[arm64-v8a] Compile++ : avs <= video_renderer.cc
[arm64-v8a] Compile++ : avs <= audio_effect.cc
[arm64-v8a] SharedLibrary : libavs.so

/home/ryan/devtools/android-ndk-r16b/build/../sources/cxx-stl/llvm-libc++/libs/arm64-v8a/libc++_static.a(locale.o): In function float std::__ndk1::__do_strtod<float>(char const*, char**)': /usr/local/google/buildbot/src/android/ndk-release-r16/external/libcxx/include/locale:807: undefined reference to strtof_l'
/home/ryan/devtools/android-ndk-r16b/build/../sources/cxx-stl/llvm-libc++/libs/arm64-v8a/libc++_static.a(locale.o): In function double std::__ndk1::__do_strtod<double>(char const*, char**)': /usr/local/google/buildbot/src/android/ndk-release-r16/external/libcxx/include/locale:813: undefined reference to strtod_l'
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [obj/local/arm64-v8a/libavs.so] Error 1
make[1]: Leaving directory `/home/ryan/wire-audio-video-signaling/android'
mk/dist.mk:149: recipe for target '/home/ryan/wire-audio-video-signaling/build/dist/android/avs.aar' failed
make: *** [/home/ryan/wire-audio-video-signaling/build/dist/android/avs.aar] Error 2

I had try NDK r16b 、r17、r18、r19、r20. All are same error.
I don't know how to solve this problem. who can help me? thanks.

I create this issue to represent the web front-end concerns written up at https://crysp.uwaterloo.ca/opinion/wire/ .

The Wire implementation is extremely complex, making the attack surface relatively large. The desktop application is implemented as a packaged web application. Each time that the application is launched, large parts of the code (written in JavaScript) are re-downloaded and executed from the Wire servers without user interaction. Essentially, the Wire app itself is merely an embedded web browser. There does not appear to be any notion of "JavaScript pinning".

A common weakness of all secure messaging applications is that the application must be downloaded, trusted, and updated regularly; if the update mechanism is ever compromised, the system can be made to arbitrarily deviate from the specifications to the benefit of the attacker. However, the current design of the Wire desktop application makes such attacks simple, difficult to detect, and rapid. Moreover, the complexity of the application and its libraries presents many opportunities for security vulnerabilities. While this complexity may be necessary to support the rich feature integrations of the platform and the broad system support, the cost is more opportunity for exploitation.

There is no such dependency on home-brew( or it has been removed):

brew info multirust
Error: No available formula with the name "multirust"
==> Searching for a previously deleted formula (in the last month)...
Warning: homebrew/core is shallow clone. To get complete history run:
git -C "$(brew --repo homebrew/core)" fetch --unshallow

Error: No previously deleted formula found.

When I tried to build multirust from source it failed on fetching one of its submodule:

git clone --depth=1 https://github.com/brson/multirust && cd multirust
...
git submodule update --init --recursive
fatal: not a git repository (or any of the parent directories): .git
newrock@ZhaodeMac-mini GitProject % cd multirust
newrock@ZhaodeMac-mini multirust % git submodule update --init --recursive
error: Server does not allow request for unadvertised object aa5ffc99caf4864b2928bc5d5be37c483ab0eba0
Fetched in submodule path 'src/rustup', but it did not contain aa5ffc99caf4864b2928bc5d5be37c483ab0eba0. Direct fetching of that commit failed.

And the README says it has migrated to rustup.rs

Any ideas to make it work? Thanks in advance.

I would like to point out that identifiers like "AVS_H__" and "ZCLIENTCALL__ENGINE_H" do eventually not fit to the expected naming convention of the C++ language standard.
Would you like to adjust your selection for unique names?