summaryrefslogtreecommitdiff
path: root/SECURITY
blob: bbd44d0a067b9c02896595aae365da30952ab753 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
custodian-enqueue
-----------------

  We open named files from the user to parse tests.  The configuration file(s)
 are currently opened by root, via /etc/service/custodian-enqueue.  This should
 be changed to run as a lower-privileged user.



custodian-dequeue
-----------------

Two tests pass arguments from the configuration file to the shell:

    ping
    http/https

The hostname used to ping, and the URL for web-tests, are both passed directly to the shell assuming they match the following regular expression:

^([^\s]+)\s+

So the following configuration file potentially allows a command to be executed by our worker:

    $(/home/steve/hg/custodian/exploit.sh) must ping otherwise "Owned".

    http://$(/tmp/exploit.sh)/ must run http with status 200 otherwise "Owned".

Given that anybody who can talk to the beanstalkd server can submit JSON-encoded-jobs we cannot rely on catching this solely in the parser.

For the moment we've solved the case of the ping-exploitation, by validating
that hostnames passed to the multi-ping command match ^[a-z0-9.-]$ - both forms
of input are validated:

  * Ensuring the hostname is valid prior to executing the shell command.

  * Ensure the hostname is valid before adding the job to the queue.


For HTTP-testing we're avoiding the shell by using the array-based invokation
of the curl command.  We don't perform validation on the URL though, because
that is a significantly harder jhob.




General
-------

We decode arbitrary JSON from the queue.  We should sign it, or validate it to  will prevent trojan malformed
JSON from being added.

At the moment we ensure that the job-body we retrieve looks JSON-like, and decodes to a non-empty hash.

Problem: We cannot sign the body without giving away our key details.

Solution: Read /etc/custodian/salt, and store the checksum of all keys + values with that salt?




TODO
----

  Anything else?  DoS attacks?



Steve
--