Commit graph

1353 commits

Author SHA1 Message Date
3650bb0370 Changelog entry 2024-03-30 11:44:34 +00:00
ee7d98b093 Update Changelog 2024-03-29 08:35:15 -01:00
0ec62acb9d Always insert Dedupe upload filter
This actually was already intended before to eradict all future
path-traversal-style exploits and to fix issues with some
characters like akkoma#610 in 0b2ec0ccee. However, Dedupe and
AnonymizeFilename got mixed up. The latter only anonymises the name
in Content-Disposition headers GET parameters (with link_name),
_not_ the upload path.

Even without Dedupe, the upload path is prefixed by an UUID,
so it _should_ already be hard to guess for attackers. But now
we actually can be sure no path shenanigangs occur, uploads
reliably work and save some disk space.

While this makes the final path predictable, this prediction is
not exploitable. Insertion of a back-reference to the upload
itself requires pulling off a successfull preimage attack against
SHA-256, which is deemed infeasible for the foreseeable futures.

Dedupe was already included in the default list in config.exs
since 28cfb2c37a, but this will get overridde by whatever the
config generated by the "pleroma.instance gen" task chose.

Upload+delete tests running in parallel using Dedupe might be flaky, but
this was already true before and needs its own commit to fix eventually.
2024-03-18 22:33:10 -01:00
fef773ca35 Drop media base_url default and recommend different domain
Same-domain setups enabled now at least two exploits,
so they ought to be discouraged and definitely not be the default.
2024-03-18 22:33:10 -01:00
f7c9793542 Sanitise Content-Type of uploads
The lack thereof enables spoofing ActivityPub objects.

A malicious user could upload fake activities as attachments
and (if having access to remote search) trick local and remote
fedi instances into fetching and processing it as a valid object.

If uploads are hosted on the same domain as the instance itself,
it is possible for anyone with upload access to impersonate(!)
other users of the same instance.
If uploads are exclusively hosted on a different domain, even the most
basic check of domain of the object id and fetch url matching should
prevent impersonation. However, it may still be possible to trick
servers into accepting bogus users on the upload (sub)domain and bogus
notes attributed to such users.
Instances which later migrated to a different domain and have a
permissive redirect rule in place can still be vulnerable.
If — like Akkoma — the fetching server is overly permissive with
redirects, impersonation still works.

This was possible because Plug.Static also uses our custom
MIME type mappings used for actually authentic AP objects.

Provided external storage providers don’t somehow return ActivityStream
Content-Types on their own, instances using those are also safe against
their users being spoofed via uploads.

Akkoma instances using the OnlyMedia upload filter
cannot be exploited as a vector in this way — IF the
fetching server validates the Content-Type of
fetched objects (Akkoma itself does this already).

However, restricting uploads to only multimedia files may be a bit too
heavy-handed. Instead this commit will restrict the returned
Content-Type headers for user uploaded files to a safe subset, falling
back to generic 'application/octet-stream' for anything else.
This will also protect against non-AP payloads as e.g. used in
past frontend code injection attacks.

It’s a slight regression in user comfort, if say PDFs are uploaded,
but this trade-off seems fairly acceptable.

(Note, just excluding our own custom types would offer no protection
 against non-AP payloads and bear a (perhaps small) risk of a silent
 regression should MIME ever decide to add a canonical extension for
 ActivityPub objects)

Now, one might expect there to be other defence mechanisms
besides Content-Type preventing counterfeits from being accepted,
like e.g. validation of the queried URL and AP ID matching.
Inserting a self-reference into our uploads is hard, but unfortunately
*oma does not verify the id in such a way and happily accepts _anything_
from the same domain (without even considering redirects).
E.g. Sharkey (and possibly other *keys) seem to attempt to guard
against this by immediately refetching the object from its ID, but
this is easily circumvented by just uploading two payloads with the
ID of one linking to the other.

Unfortunately *oma is thus _both_ a vector for spoofing and
vulnerable to those spoof payloads, resulting in an easy way
to impersonate our users.

Similar flaws exists for emoji and media proxy.

Subsequent commits will fix this by rigorously sanitising
content types in more areas, hardening our checks, improving
the default config and discouraging insecure config options.
2024-03-18 22:33:10 -01:00
889b57df82 2024.02 release 2024-02-24 13:54:21 +00:00
e99e2407f3 Add background_removal to SimplePolicy MRF 2024-02-16 16:36:45 +01:00
7622aa27ca Federate user profile background
Currently our own frontend doesn’t show backgrounds of other users, this
property is already publicly readable via REST API and likely was always
intended to be shown and federated.

Recently Sharkey added support for profile backgrounds and
immediately made them federate and be displayed to others.
We use the same AP field as Sharkey here which should make
it interoperable both ways out-of-the-box.

Ref.: 4e64397635
2024-02-16 16:35:51 +01:00
0ed815b8a1 Merge branch 'followback' into develop 2024-02-16 13:27:40 +00:00
6bb455702d Document Akkoma API 2024-02-15 16:04:33 +01:00
376f6b15ca Add ability to auto-approve followbacks
Resolves: AkkomaGang/akkoma#148
2024-02-13 15:42:37 +01:00
e47c50666d Fix obfuscation of short domains
Fixes AkkomaGang/akkoma#645
2024-02-02 14:50:13 +00:00
2858cd81e1 Move changelog into our format 2023-12-15 16:32:41 +00:00
d1af78aba1 changelog 2023-09-15 12:00:45 +01:00
063e3c0d34 Disallow nil hosts in should_federate 2023-08-15 23:12:04 +01:00
6cb40bee26 Migrate to phoenix 1.7 (#626)
Closes #612

Co-authored-by: tusooa <tusooa@kazv.moe>
Reviewed-on: AkkomaGang/akkoma#626
Co-authored-by: FloatingGhost <hannah@coffee-and-dreams.uk>
Co-committed-by: FloatingGhost <hannah@coffee-and-dreams.uk>
2023-08-15 10:22:18 +00:00
1bd3012c2d Fix compiler warnings 2023-08-12 15:03:43 +01:00
7bd4ae5412 Bump builds to OTP26 2023-08-09 14:39:28 +01:00
80cbdc8480 changelog 2023-08-07 16:27:23 +01:00
0c21341156 Fix signature checking 2023-08-07 16:17:17 +01:00
mae
d868348fac Completely disable xml entity resolution 2023-08-05 12:32:05 +00:00
cc2614e10b Bump version 2023-08-05 13:26:42 +01:00
b4399574ca Merge remote-tracking branch 'norm/config-permissions' into develop 2023-08-04 22:31:11 +01:00
9c7409808f Add unit test for external entity loading 2023-08-04 22:24:32 +01:00
8fd74548ff Combine ubuntu and debian builds 2023-08-04 20:37:17 +01:00
Haelwenn (lanodan) Monnier
bfebb92bea
changelog: Entry for config permissions restrictions
Original: 9f0ad901ed
2023-08-04 14:14:14 -04:00
0b2ec0ccee Enable AnonymizeFilenames on all uploads 2023-08-04 15:37:15 +01:00
1a88d9278b Changelog entry 2023-08-04 15:19:06 +01:00
8cebd74b0a update typo, sslv3 2023-08-04 12:02:57 +01:00
98cb255d12 Support elixir1.15
OTP builds to 1.15

Changelog entry

Ensure policies are fully loaded

Fix :warn

use main branch for linkify

Fix warn in tests

Migrations for phoenix 1.17

Revert "Migrations for phoenix 1.17"

This reverts commit 6a3b2f15b74ea5e33150529385215b7a531f3999.

Oban upgrade

Add default empty whitelist

mix format

limit test to amd64

OTP 26 tests for 1.15

use OTP_VERSION tag

baka

just 1.15

Massive deps update

Update locale, deps

Mix format

shell????

multiline???

?

max cases 1

use assert_recieve

don't put_env in async tests

don't async conn/fs tests

mix format

FIx some uploader issues

Fix tests
2023-08-03 17:44:09 +01:00
1e66cec654 changelog 2023-08-01 11:26:59 +01:00
801fe9fe32 Changelog 2023-07-27 14:41:18 +01:00
Weblate
eba3cce77b Update translation files
Updated by "Squash Git commits" hook in Weblate.

Translation: Pleroma fe/Akkoma Backend (Config Descriptions)
Translate-URL: http://translate.akkoma.dev/projects/akkoma/akkoma-backend-config-descriptions/
2023-07-27 13:14:05 +00:00
db64556306
Record no_new_privs hardening to changelog 2023-07-22 02:41:35 -04:00
f1611b6292 Update changelog 2023-07-17 19:19:03 +01:00
16d2bfef80 Ensure embeds will not be served if unauthenticated users could not see it 2023-07-17 18:24:53 +01:00
8c956bc671 Add OnlyMedia upload filter change to changelog 2023-06-28 01:56:34 +01:00
XxXCertifiedForkliftDriverXxX
07b478dc49 Implement blocklists for MediaProxy 2023-06-26 15:18:31 +02:00
7fb9960ccd Add CSP to mediaproxy links 2023-05-26 11:46:18 +01:00
82ca7a6470 bump version 2023-05-23 14:10:01 +01:00
037f881187 Fix create processing in direct message disabled 2023-05-23 13:16:20 +01:00
b86b3a9e29 Support public key URIs that incomprehensibly have GET args
Fixes #528
2023-04-25 13:30:20 +01:00
963d29ad8c 2023.04 Release 2023-04-14 18:00:59 +01:00
f2b4e7f86b Merge branch 'develop' of akkoma.dev:AkkomaGang/akkoma into develop 2023-04-14 17:56:56 +01:00
8c86a06ed1 Merge pull request 'Remove "default" image description' (#493) from ilja/akkoma:remove_default_image_description into develop
Reviewed-on: AkkomaGang/akkoma#493
2023-04-14 16:27:41 +00:00
ba59fdcd54 add changelog entry 2023-04-14 16:56:51 +01:00
dd44387f1a Add timeline visibility options 2023-03-17 15:33:28 +00:00
86a5cf3c82 Changelog entry 2023-03-15 22:20:32 +00:00
ilja
6c396fcab4 Remove "default" image description
When no image description is filled in, Pleroma allowed fallbacks.
Those were (based on a setting) either the filename, or a fixed description.
Neither are good options for image descriptions imo, so here we remove this.

Note that there's two tests removed who supposedly tested something else.
But examining closer, they didn't seem to test what they claimed to test,
so I removed them rather than try to "fix" them.
2023-03-12 08:42:33 +01:00
800fe40407 Bump version 2023-03-11 17:26:21 +00:00