Asepsis 1.5 security vulnerability

Asepsis
1

Hello,

as far as I’m concerned /usr/local/.dscage directory is used by asepsis.

Currently it’s world writable, and also every directory underneath is world writable.

This creates quite a bunch of security problems.

Any comments on it?

2

I’m not a security expert. Can you elaborate in what scenario it can be dangerous?

Asepsis code gets injected into all processes linking with DesktopServicesPriv.framework (potentially running under different users and groups). And all those processes need potentially read/write .DS_store files in /usr/local/.dscage.

3

Multiple.

I can (as a user A) for example link /usr/local/.dscage/some/easy/toguess/file to any critical file owned by user B, with it being in effect overwritten by asepsis process.

This is simplest example, and there is multiple attack vectors (different), as a world writeable directory with writes to filenames (known apriori by attacker) by multiple unsuspecting different UID processes is heavily exploitable.

I don’t know aspesis architecture so it’s hard for me to recommend a solution but (with differences between easiness to implement and security) few fast ones:

  1. only in memory store (lost on reboots)
  2. separate UID used only by asepsis
  3. separate daemon receiving data to be stored over some form of IPC → this is probably mostly used solution in this problem domain: you can analyse how SMTP servers handle this (e.g. postfix).
4

I can see that some attacker could get information about user’s directory structure by observing .dscage folder. In .dscage there are no critical files AFAIK. .DS_store files contain some metadata.

I can imagine a better version of Asepsis storing .dscage folder under user’s home folder and having it only user-writable. But I don’t know if this restriction would cause any troubles. Users wouldn’t be able to share their .DS_store settings system-wide (which is not a strong requirement anyway).

5

Hi

.dscage definitely should be under users directory, and not world writable. I’d gladly resign from storing settings system-wide.

This security vulnerability can be exploited also in different ways (stealling ssh keys, overwriting critical user files, stealing authentication cookies and passwords).

Any ETA when would you like to release security update?