-
Notifications
You must be signed in to change notification settings - Fork 1
/
HACKING.txt
executable file
·172 lines (143 loc) · 9.5 KB
/
HACKING.txt
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
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
Please attack Phreebird. I'm serious, nothing would be better than having six
critical vulnerabilities found in the first week.
Better the first week than the first month, better the first month than the
first year, and better the first year than our standard operating procedure of
taking half a decade to realize there's a problem!
Here's what I know is wrong thus far.
KNOWN BUGS:
1) Phreebird leaks memory over time, mainly because LDNS wasn't really designed
to allow lots of very complicated transforms. I'm working on fixing this,
but as is, Phreebird will leak memory under even mild DoS conditions.
Obviously that's a production blocking bug.
2) Phreebird now has a maximum size for the cache -- 10*1024 buckets, with a
maximum of 50 entries per bucket. Theoretically, that's around 500,000 cache
entries, which at 1K a piece might be 500MB. It'd probably be a good idea to
make that tunable.
3) Phreebird doesn't correctly reflect EDNS0 maximum packet size data, though
it should *respect* the maximum size the user wants to receive.
4) Phreebird doesn't correctly support backend domains that aren't two labels,
i.e. foo.co.uk. This will be fixed as soon as I actually get access to such a
domain.
5) Phreebird, as a UDP proxy, does cause the backend server to lose context on
what IP it's talking to. So one of the big advantages of the Phreebird
approach -- that you can sign any answer -- is sort of impacted. See source
code for details on how this will be fixed.
6) Phreebird does not yet support delegation, i.e. scenarios where the backend
name server itself has a DS record for a domain.
7) Should probably not have arbitrary NSEC3 keytag of 1290
8) I don't think I'm merging adjacent sub-TXT records.
9) Something is causing corrupt packets to be returned every so often, a la:
;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Nov 11 05:45:57 2010
;; MSG SIZE rcvd: 1187
;; Got bad packet: FORMERR
1185 bytes
0a 04 85 83 00 01 00 00 00 08 00 01 04 38 36 37 .............867
39 04 70 62 2d 61 03 6f 72 67 00 00 01 00 01 04 9.pb-a.org......
70 62 2d 61 03 6f 72 67 00 00 06 00 01 00 00 00 pb-a.org........
1e 00 2f 09 6c 6f 63 61 6c 68 6f 73 74 00 04 72 ../.localhost..r
6f 6f 74 09 6c 6f 63 61 6c 68 6f 73 74 00 00 00 oot.localhost...
00 03 00 09 3a 80 00 01 51 80 00 24 ea 00 00 09 ....:...Q..$....
3a 80 04 70 62 2d 61 03 6f 72 67 00 00 2e 00 01 :..pb-a.org.....
00 00 00 1e 00 9c 00 06 07 02 00 00 00 1e 4d 00 ..............M.
6d 09 4c db 83 09 32 27 04 70 62 2d 61 03 6f 72 m.L...2'.pb-a.or
67 00 2d de 33 56 34 bb bb 8d 78 7f 27 92 99 c3 g.-.3V4...x.'...
ac 21 fb bf b9 4f bb 05 fc b8 6e 64 e7 55 08 4c .!...O....nd.U.L
ef 43 b6 62 16 50 3c ea e0 2d 54 47 cb 57 ed 68 .C.b.P<..-TG.W.h
56 52 21 23 2d e7 a7 19 23 b1 95 61 cd da 55 da VR!#-...#..a..U.
8e 31 33 bb 55 97 ba 0a ad 6b 74 3c 29 77 07 96 .13.U....kt<)w..
6b ad 53 40 b0 2a 1f cc 7a 26 2f 09 98 b8 f0 f2 k.S@.*..z&/.....
02 0d 65 4a fa bc a5 eb 76 d4 55 cd 7b 21 9c e0 ..eJ....v.U.{!..
ce 06 1d 94 1b fe 47 3c 3e c1 11 c1 e7 ea 71 e5 ......G<>.....q.
db a4 20 38 6a 71 37 39 68 76 65 6b 61 61 6d 33 ...8jq79hvekaam3
32 6c 35 35 76 35 37 33 61 6b 76 74 71 6e 34 71 2l55v573akvtqn4q
6d 67 3d 04 70 62 2d 61 03 6f 72 67 00 00 32 00 mg=.pb-a.org..2.
01 00 00 00 00 00 23 01 00 00 01 02 12 90 14 44 ......#........D
f4 74 c7 ee a2 95 61 8a a5 2f ca 71 aa 9f ee ae .t....a../.q....
4d 5c 00 06 40 00 00 00 00 02 20 38 6a 71 37 39 M\[email protected]
68 76 65 6b 61 61 6d 33 32 6c 35 35 76 35 37 33 hvekaam32l55v573
61 6b 76 74 71 6e 34 71 6d 67 3d 04 70 62 2d 61 akvtqn4qmg=.pb-a
03 6f 72 67 00 00 2e 00 01 00 00 00 00 00 9c 00 .org............
32 07 03 00 00 00 00 4d 00 6d 15 4c db 83 15 32 2......M.m.L...2
27 04 70 62 2d 61 03 6f 72 67 00 49 ba c3 9b cb '.pb-a.org.I....
6d 71 8b db 3d d7 94 0b 2b 40 b5 89 6c f4 da d2 [email protected]...
e9 92 2d 22 7f 5d 75 41 77 3e 21 fd 52 4a 75 d3 ..-".]uAw>!.RJu.
16 98 7b 3e f5 38 3d 30 85 5b 13 8b 84 c3 ae 5e ..{>.8=0.[.....^
c8 8a 3b e0 17 0d 50 db f1 f7 f8 7b f5 54 92 26 ..;...P....{.T.&
4f 14 ec 85 d2 d4 ab 7d a9 72 8f d9 f0 a7 22 d2 O......}.r....".
6e c0 6a 63 94 0b e7 15 72 98 df 85 cc 58 2a 44 n.jc....r....X*D
fe ca 2c 3c e0 fa 3a c0 37 a1 01 e9 7d 12 52 32 ..,<..:.7...}.R2
91 e3 96 0f 79 8a b2 5b 8c 39 a8 20 76 34 39 73 ....y..[.9..v49s
64 73 30 69 75 6c 6a 72 6c 76 66 76 69 70 6d 71 ds0iuljrlvfvipmq
69 35 66 33 75 64 61 62 38 34 67 6c 04 70 62 2d i5f3udab84gl.pb-
61 03 6f 72 67 00 00 32 00 01 00 00 00 00 00 2b a.org..2.......+
01 00 00 01 02 12 90 14 f9 13 c6 f0 12 f5 67 ba ..............g.
fd ff 96 6d a9 15 e3 f3 54 b4 12 16 00 0d e6 3d ...m....T......=
80 0c 54 1f f0 00 00 00 00 00 10 20 76 34 39 73 ..T.........v49s
64 73 30 69 75 6c 6a 72 6c 76 66 76 69 70 6d 71 ds0iuljrlvfvipmq
69 35 66 33 75 64 61 62 38 34 67 6c 04 70 62 2d i5f3udab84gl.pb-
61 03 6f 72 67 00 00 2e 00 01 00 00 00 00 00 9c a.org...........
00 32 07 03 00 00 00 00 4d 00 6d 09 4c db 83 09 .2......M.m.L...
32 27 04 70 62 2d 61 03 6f 72 67 00 4d aa ec c5 2'.pb-a.org.M...
b3 8e ac b0 83 82 a1 7c f8 77 8d b6 6c 6c a2 c3 .......|.w..ll..
15 38 b9 93 35 2c 29 f2 dc 49 28 9a eb b2 97 67 .8..5,)..I(....g
84 ec ae ab 8f ff ee bd 5b 8c 59 69 14 b4 8a 7d ........[.Yi...}
3a 5b 02 a2 31 12 9f a6 e3 f5 e3 3f 20 46 70 58 :[..1......?.FpX
70 4f 74 95 ef a6 ef 4a 40 d0 78 73 9d d6 dd 23 [email protected]...#
01 01 30 e6 3a 8c 05 75 75 60 0e a0 92 a8 b4 76 ..0.:..uu`.....v
15 13 b3 5f 2c 78 4e e9 9c 66 6d 3c b5 ab fc 57 ..._,xN..fm<...W
f6 25 34 a4 35 56 cd 8e d8 bb 83 7b 20 38 67 6e .%4.5V.....{.8gn
34 65 70 67 63 30 63 74 36 36 36 30 36 75 69 73 4epgc0ct66606uis
6e 70 35 66 39 62 38 76 6e 73 35 70 65 04 70 62 np5f9b8vns5pe.pb
2d 61 03 6f 72 67 00 00 32 00 01 00 00 00 00 00 -a.org..2.......
24 01 00 00 01 02 12 90 14 44 2e 47 66 0c 03 3a $........D.Gf..:
63 18 06 f4 b9 7c 95 e9 5a 3f 7e 17 30 00 06 40 c....|..Z?..0..@
00 00 00 00 02 20 38 67 6e 34 65 70 67 63 30 63 ......8gn4epgc0c
74 36 36 36 30 36 75 69 73 6e 70 35 66 39 62 38 t66606uisnp5f9b8
76 6e 73 35 70 65 04 70 62 2d 61 03 6f 72 67 00 vns5pe.pb-a.org.
00 2e 00 01 00 00 00 00 00 9c 00 32 07 03 00 00 ...........2....
00 00 4d 00 6d 09 4c db 83 09 32 27 04 70 62 2d ..M.m.L...2'.pb-
61 03 6f 72 67 00 90 32 db ed 00 2c ac 1d d6 b8 a.org..2...,....
b0 9e 6a 41 96 6f 32 f6 b1 e2 8f b2 46 2b 8c 1e ..jA.o2.....F+..
ef 82 e4 86 12 61 86 3d 74 6a b3 e7 21 a8 15 94 .....a.=tj..!...
c9 8b 4e 91 83 a0 6e e2 85 c5 ca cd 4d a9 bb 1f ..N...n.....M...
ca 83 63 33 f7 cc 14 ce 86 4f 03 26 98 99 69 f7 ..c3.....O.&..i.
2e c8 ec 2f 9b 4d cb 84 34 26 f1 ea 3e 7a e9 b4 .../.M..4&..>z..
c2 ba 2a 3d 48 f4 bb 82 15 7d 10 db f0 31 55 43 ..*=H....}...1UC
09 12 9f 7b 54 16 86 89 53 b6 39 39 3d da 4e 6e ...{T...S.99=.Nn
5f 19 5a d7 45 a6 00 00 29 10 00 00 00 80 00 00 _.Z.E...).......
00 .
Don't know what -- could be me, could be ldns.
KNOWN HEEBIE JEEBIES:
1) LDNS makes it really annoying to build certain packets without essentially
doing string concatenation. For example:
snprintf(nsec_descrip, sizeof(nsec_descrip), "%s.%s 0 IN NSEC3 1 0 1 1290 %s %s",
lhash, shortname_buf->_data, rhash, mask);
Now, there's validation going on in validate name, which is basically
restricting to a-zA-Z0-9 and making sure there aren't two dots in a row, but
something hinky coould happen here.
2) LDNS Chasing *looks* like it should be correct, but unlike Unbound Tracing,
it's not actually doing the full DNSSEC negotiation all the way from root. If
there's going to be a design bug anywhere, it's going to be here.
3) Unbound Tracing is not actually something we want every host on the Internet
doing -- it increases traffic to the root and TLDs substantially. This is made
worse by the fact that, even thought the Unbound ctx is being cached, lookups
against the root keep happening. If you're wondering why unbound lookups seem
slow, this is why. You can speed unbound up substantally by turning off IPv6,
but that causes its own headaches (we need v6).
4) The present design really does push people into hardcoding the DNSSEC root
key into their apps. The purists really do want people to be able to cycle
that key, and there's even an RFC (5011) for doing that. Epic handwringing,
inbound.
5) I could use a real configure script.
6) I'm not entirely confident about my handling of TXT records in Phreeload.
There could straight up be some RCE in here.
KNOWN NOT A BUG:
1) If an attacker can spoof traffic between a Phreebird proxy and its backend,
he can do truly awful things with relatively few spoofed packets. There's a
reason this is warned about during execution.
2) Phreebird doesn't daemonize yet. I'll build that feature in when I'm
confident there are no production blockers.
3) No, I'm not using your pet DNSSEC schema yet. Convince me yours is better, or
fork my code!