blob: 42ffc187d6d33b9e4e464158d7454527836cb66b (
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 a single named file so that we may parse tests. There seems no harm in this,
because the user must have permission to parse the file.
To successfully enqueue jobs that have been parsed the user must be able to talk to the
beanstalkd queue - but this happens over TCP, so there is no need to run the parsing
tool as root, and this is generally discouraged.
Conclusion: The enqueuing process contains no security risks.
custodian-dequeue
-----------------
Only one test ultimately passes arguments from the queue/configuration file to a system command:
ping
The hostname passed to the ping-tool will initially be matched against the regular expression:
^([^\s]+)\s+
So the following configuration file snippet potentially allows a command to be executed by our worker:
$(/home/steve/hg/custodian/exploit.sh) must ping otherwise "Owned".
Given that anybody who can talk to the beanstalkd server can submit 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.-]$ - in both
possible forms:
* Ensuring the hostname is valid prior to executing the shell command.
* Ensure the hostname is valid before adding the job to the queue.
We are careful to run the system command in the Ruby array-format, which will bypass shell
exploitation.
Conclusion: There are no obvious security concerns in the dequeuing process.
General
-------
We pull arbitrary jobs from the queue, and it is possible an attacker could add malicious
entries.
We could sign tests to prevent trojan malformed lines from being processed, but this is
not yet done. (It isn't obvious if this would be a sensible addition either.)
Anything else?
--------------
DoS attacks seem likely - the simple case would be to stuff the queue with sufficiently many
"bogus" jobs that "real" jobs are never completed.
Steve
--
|
