Security Advisory for Tauri 1.4 (CVE-2023-34460)

This post shares insight into the most recent Tauri security advisory, affecting the Tauri 1.4 release. You can learn more about the release itself on the Tauri Blog Post.

The issue was discovered during an internal audit performed by our Director of Security Tillmann Weidinger and Security Engineer Chip Reed. This audit was internal in the sense that we are also involved in the open source project itself but performed the audit with the resources of CrabNebula. Calling it external security audit would create false impressions.

Details of CVE-2023-34460

This discovery was a regression of a previous security change CVE-2022-46171. In the previous advisory it was discovered that the [glob](https://docs.rs/glob/latest/glob/) crate has some potentially insecure default values, by allowing to read dotfiles (require_literal_leading_dot: false) on Unix systems and matching path separators with wildcards (require_literal_separator: false).

It was decided to harden these settings, therefore the default values were set to true. After the 1.3 release some usability issues were reported to the Tauri project, which introduced the need to allow application developers to modify these values to their need.

The change in the 1.4 release introduced the [require_literal_leading_dot](https://tauri.app/v1/api/config/#fsallowlistscope.requireliteralleadingdot) option in the tauri.conf.json, but the default behavior for this switch was accidentally reverted to the previous default. This allowed reading of dotfiles by default, when wildcards like * or ? were used in the scope of the fs module.

tauri/core/tauri/src/scope/fs.rs#L110-L120

let require_literal_leading_dot = match scope {
  FsAllowlistScope::Scope {
    require_literal_leading_dot: Some(require),
    ..
  } => *require,
  // dotfiles are not supposed to be exposed by default on unix
  #[cfg(unix)]
  _ => false,
  #[cfg(windows)]
  _ => true,
};

A vulnerable configuration could look like:

"allowlist": {
  "fs": {
    "readFile": true,
    "scope": {
      "allow": ["$HOME/**"]
    }
  }
}

The impact of the regression could be worked around by adding the configuration flag manually:

"security": {
  "fs": {
    "readFile": true,
    "scope": {
      "allow": ["$HOME/**"],
      "requireLiteralLeadingDot": true
    }
  }
}

To properly fix this behavior the option now requires a literal leading dot by default on Unix systems, as documented and commented in the code.

tauri/core/tauri/src/scope/fs.rs#L115-L119

// dotfiles are not supposed to be exposed by default on unix
#[cfg(unix)]
_ => true,
#[cfg(windows)]
_ => false,

Conclusion

As this issue only affects applications with wildcard scopes in their fs endpoint, is restricted to Unix (macOS and Linux in this instance) and can be fixed by manually setting the correct behavior in the configuration. We concluded that this has only low to moderate impact.

If you have any further questions, comments, or remarks, feel free to reach out to us at CrabNebula Consulting.

Open source is one of the core values for us at CrabNebula. We believe in making software accessible to everyone and our continued investment in Tauri is just one of the ways that we work to make that possible. Learn more about CrabNebula.

Authors: Tillmann Weidinger, Director of Security & Chip Reed, Security Engineer