Git-Mirrors/veilid
1
0
Fork 0
mirror of https://gitlab.com/veilid/veilid.git synced 2024-10-01 01:26:08 -04:00
Code Issues Packages Projects Releases Wiki Activity
1,159 Commits 5 Branches 15 Tags 72 MiB
Rust 77.5%
Dart 13.1%
Python 3.9%
Shell 2.5%
TypeScript 0.7%
Other 2%
4873a0c0c9
Go to file
Rivka Segan 4873a0c0c9 Avoid large logs of 127.0.0.1:5959 attack payloads 
Because veilid-server listens on 127.0.0.1 TCP port 5959, it is
potentially open to attacks from websites if a user runs an ordinary
web browser (e.g., Chrome or Firefox) on the same computer.
Specifically, any https website can include JavaScript code that
begins with

   let message = 'WASTE_YOUR_VEILID_SERVER_DISK_SPACE_'.repeat(1000);

   fetch('http://127.0.0.1:5959/' + message)

and the web browser will then send many KB of data to veilid-server,
where it may typically be logged to disk by this code:
2ab51ae3e9/veilid-core/src/veilid_api/serialize_helpers/serialize_json.rs (L6-L12)

(Because Veilid hasn't even reached 1.0, it's very common for users to
enable a large amount of logging.)

The threat model is that someone creates a website that's apparently
of interest to any Veilid user, but the actual purpose of the website
is to leverage the user's web browser to silently tunnel an attack
payload into another application that is local to the user. An attack
that sends more than 1 MB of data (for each fetch API call) is
feasible, and the patch in this MR tries to address that.

Note that the most common web browsers always allow JavaScript on
arbitrary https websites to send data to 127.0.0.1 port 5959, there is
no configuration menu to shut this off, and the user is not alerted
that this is occurring. Brave 1.54 (June 2023) was the first popular
web browser to block this:
https://brave.com/privacy-updates/27-localhost-permission/

This does not mean that an adversary can just as easily setup a
website to send:

  {"op":"Control","args":["Shutdown"],"id":1}

to 127.0.0.1 TCP port 5959 and thereby terminate a veilid-server
process. A web browser using http will always send requests that begin
with specific strings (such as GET or OPTIONS) on the first line, and
the code at:

2ab51ae3e9/veilid-server/src/client_api.rs (L367)

2ab51ae3e9/veilid-server/src/client_api.rs (L244)

2ab51ae3e9/veilid-server/src/client_api.rs (L202)

seems to work together to ensure that no JSON object results in
command execution unless the first line of the input is a JSON object.
(Not sure if this was a design goal, or simply how it turned out.)

A web browser can do other things besides cleartext http (e.g., try to
start a TLS session to 127.0.0.1 TCP port 5959), but it's perhaps
unlikely that the initial bytes of the network traffic, in the context
of the above threat model, would ever be a JSON object.

Note that, although veilid-server is not speaking the HTTP protocol on
127.0.0.1 TCP port 5959, it is still able to read the data sent by any
web browser to http://127.0.0.1:5959, send that data to a JSON parser,
and write the data to the server logs. In limited testing, the HTTP
client typically saw zero bytes of application layer response;
however, if the HTTP client sent a huge amount of data (e.g., 16 MB),
the HTTP client would sometimes receive a large response with JSON
data about veilid-server's internal state. That might be a separate
bug. In the context of the threat model, this may not matter because
that JSON data isn't accessible by the operator of the website (that
hosts the JavaScript code).

There may be many ways to resolve this. First, the Veilid
documentation could recommend never running a web browser on any
machine that has veilid-server with 127.0.0.1 TCP port 5959 open.
Second, the existence of a realistically probe-able service on
127.0.0.1 TCP port 5959 might be considered much too large an attack
surface for an application of Veilid's sensitivity, and interprocess
communication could be replaced with something other than
unauthenticated TCP.

This MR is intended to improve Veilid for an ordinary user who wants
to help the project by installing veilid-server on their primary
personal machine, and wants veilid-cli to remain usable, but needs to
continue routine web browsing on that machine. It provides safer
behavior for such a person. The MR is not intended to benefit experts
who already understand localhost TCP risks, and either avoid all web
browsing on the same machine or have their own countermeasures. These
experts will not see any attacker-controlled traffic on port 5959, and
thus the reduction in logging should be of no concern to them.

Without the patch (and with logging on), data sent by a web browser is
always logged by veilid-server in the form:

   Connection processing failure: Parse error: 'expected value at line 1 column 1' with value 'deserialize_json:
   ---
   GET /<attacker_controlled_data> HTTP/1.1
   ---
    to type veilid_core::veilid_api::json_api::Request'

regardless of how long the attacker controlled data is. Some browsers
such as Chrome start by sending OPTIONS instead of GET.

With the patch, long malformed input is discarded and the log instead
contains:

   Connection processing failure: Parse error: 'expected value at line 1 column 1' with value 'deserialize_json:
   ---
   :skipped long input that's not a JSON object
   ---
    to type veilid_core::veilid_api::json_api::Request'

The patch allows logging of anything where the first non-whitespace
character is a '{' - this is considered safe (at the moment) because
no web browser (realistically used by a local user) can send '{' at
the beginning of the first line. Also, the patch allows logging of
requests smaller than 50 bytes to support two use cases. First, if a
node operator is sending one of the simple JSON API requests by hand
and is accidentally omitting the initial '{' from the JSON object,
they'll be able to see the failure in their logs. Second, non-expert
node operators may want some limited visibility into the details of
adversarial activity on http://127.0.0.1:5959. Of course, this default
logging policy could be made more flexible later if Veilid decides to
stay with unauthenticated TCP. The patch only aims to defeat a simple
DoS attack against the out-of-the-box code.
2023-08-28 04:53:31 +00:00
.cargo wasm fixes 2022-11-29 22:51:51 -05:00
dev-setup Fix setup_linux.sh to use scripts from the parent directory 2023-08-19 12:29:30 -04:00
doc network fixes 2023-07-19 10:07:51 -04:00
docs/guide Initial German translation of the guide document 2023-08-26 21:17:29 +00:00
external update submodules 2023-07-19 14:41:10 -04:00
files Add Test CA and simple certs for testing 2021-11-22 09:02:41 -05:00
package service restart if running, instructs to start if not 2023-07-17 20:55:45 -05:00
scripts Fix minor typos 2023-08-21 20:12:20 -05:00
veilid-cli veilid-server with Clap v4 2023-08-22 21:12:23 +00:00
veilid-core Merge branch 'fix-set-record-data-size-call' into 'main' 2023-08-27 16:07:38 +00:00
veilid-flutter flutter fix 2023-08-24 18:35:37 -04:00
veilid-python veilid-python: update_schema.sh now checks in a few places for veilid-server 2023-08-24 23:30:44 +00:00
veilid-server Avoid large logs of 127.0.0.1:5959 attack payloads 2023-08-28 04:53:31 +00:00
veilid-tools Version update: v0.1.9 → v0.1.10 2023-08-20 11:37:18 -05:00
veilid-wasm xfer 2023-08-22 15:11:45 -04:00
.bumpversion.cfg Version update: v0.1.9 → v0.1.10 2023-08-20 11:37:18 -05:00
.earthlyignore add eartly build 2022-01-09 15:17:36 -05:00
.gitignore Ignore emacs backup files 2023-08-12 18:10:32 +02:00
.gitlab-ci.yml Earthly Build Caching in GitLab Container Registry 2023-08-27 17:17:29 +00:00
.gitmodules make submodule path absolute 2023-08-18 01:13:09 -04:00
Cargo.lock flutter fix 2023-08-24 18:35:37 -04:00
Cargo.toml version bump 2023-07-16 14:35:51 -04:00
CHANGELOG.md add more changelog and clean up test output 2023-08-20 12:10:54 -04:00
code_of_conduct.md Add docs and mod version bumping 2023-08-01 21:37:38 -05:00
CONTRIBUTING.md Update CONTRIBUTING.md 2023-08-10 19:32:36 +00:00
DEVELOPMENT.md Update DEVELOPMENT.md to reflect new paths. 2023-08-18 09:27:17 -04:00
Earthfile Earthly Build Caching in GitLab Container Registry 2023-08-27 17:17:29 +00:00
INSTALL.md Update file INSTALL.md 2023-08-24 17:41:35 +00:00
LICENSE Add LICENSE 2023-08-10 19:34:50 +00:00
README-DE.md Initial German translation of the project readme file 2023-08-26 21:41:04 +00:00
README.md fix: README typos 2023-08-12 21:17:31 -07:00
RELEASING.md Revise release process 2023-08-19 17:19:17 -05:00
version_bump.sh version 2023-07-19 13:01:55 -04:00

README.md

Welcome to Veilid

From Orbit

The first matter to address is the question "What is Veilid?" The highest-level description is that Veilid is a peer-to-peer network for easily sharing various kinds of data.

Veilid is designed with a social dimension in mind, so that each user can have their personal content stored on the network, but also can share that content with other people of their choosing, or with the entire world if they want.

The primary purpose of the Veilid network is to provide the infrastructure for a specific kind of shared data: social media in various forms. That includes light-weight content such as Twitter's tweets or Mastodon's toots, medium-weight content like images and songs, and heavy-weight content like videos. Meta-content such as personal feeds, replies, private messages, and so forth are also intended to run atop Veilid.

Run a Node

The easiest way to help grow the Veilid network is to run your own node. Every user of Veilid is a node, but some nodes help the network more than others. These network support nodes are heavier than the node a user would establish on their phone in the form of a chat or social media application. A cloud based virtual private server (VPS), such as Digital Ocean Droplets or AWS EC2, with high bandwidth, processing resources, and up time availability is crucial for building the fast, secure, and private routing that Veilid is built to provide.

To run such a node, establish a Debian or Fedora based VPS and install the veilid-server service. To make this process simple we are hosting package manager repositories for .deb and .rpm packages. See the installing guide for more information.

Development

If you're inclined to get involved in code and non-code development, please check out the contributing guide. We're striving for this project to be developed in the open and by people for people. Specific areas in which we are looking for help include:

  • Rust
  • Flutter/Dart
  • Python
  • Gitlab DevOps and CI/CD
  • Documentation
  • Security reviews
  • Linux packaging