DelphinusDNS Blog

(the latest about delphinusdnsd)

I have improved the security of the TCP process

March 24th, 2023

In this commit (github) I have changed the TCP structure a little bit. I now fork an extra child that is an "accept engine". All it does is select on the listening descriptors and accept(2)'s the socket. Once it has this it passes the socket off to the main TCP engine that used to do this task. I was able to lose the "inet" pledge in the main TCP engine and this made it worth it. However now the setup is a bit weird because the main tcp engine passes this descriptor to the parsing engine which now has comparable pledges. That's what's weird about it. But the UDP main process still needs the parser process in order to do safe parsing, why not give the tcp process it's own parser too right? It's just a bit more overhead but is acceptable to me. On my test workstation the latency of a lookup was around 1 ms on tcp.

What's next? The acceptloop() will likely see adoption in the AXFR engine as well so that it can lose it's inet pledge too. But I'm gonna take it easy for the rest of the day. I did mostly programming today.

For some eye-candy this is what a box with delphinusdnsd looks like in a process listing:

root@stern# ps ax|grep delphin
45039 ??  Spc      0:00.42 delphinusdnsd: cortex [] (delphinusdnsd)
21925 ??  Spc      0:00.64 delphinusdnsd -f /var/delphinusdnsd/etc/delphinusdns
54020 ??  Spc      0:00.02 delphinusdnsd: cortex [] (delphinusdnsd)
26945 ??  SpU      0:00.05 delphinusdnsd: primary [] (delphinusdnsd)
64451 ??  SpUc     0:00.02 delphinusdnsd: unix controlling socket [] (delphinus
40668 ??  Spc      0:00.03 delphinusdnsd: AXFR engine on port 10053 [] (delphin
81060 ??  SpUc     0:00.03 delphinusdnsd: Replicant engine [] (delphinusdnsd)
97802 ??  Spc      0:00.30 delphinusdnsd: FORWARD engine [] (delphinusdnsd)
53973 ??  Sp       0:00.13 delphinusdnsd: TCP engine 0 [] (delphinusdnsd)
78173 ??  Sp       0:00.03 delphinusdnsd: TCP parse engine 0 [] (delphinusdnsd)
60256 ??  Sp       0:00.04 delphinusdnsd: TCP accept engine 0 [] (delphinusdnsd
13609 ??  Sp       0:00.04 delphinusdnsd: udp parse engine 0 [] (delphinusdnsd)
13864 ??  Sp       0:00.04 delphinusdnsd: forward parse engine [] (delphinusdns
86423 p0  R+/1     0:00.01 grep delphin

Lots of processes...

0 comments

The memory plagues are most likely fixed now

March 23rd, 2023

I likely found the culprit. It was wrongly added on March 19th. Here is the fix to this. Whew! Thanks to Otto for some great hints!

0 comments

The last analysis was wrong

March 22nd, 2023

After I wrote this the forwarding delphinusdnsd crashed again. I guess I'm bug hunting when I find the time. This is weird! I'll get to the bottom of it one day though.

0 comments

New release probably imminent in a few days

March 22nd, 2023

I've found a bug with my memory allocation code, it has been stalling efforts to get some things encrypted in the shared memory. There is several factors involved but I think unwind(8) plays a major role in this.

I recently turned unwind on at home on my workstation and it unearthed another bug. I'm glad it does this, delphinusdnsd gets better. Anyhow I'm theorizing that unwind does a lot of lookups for the root zone for validation purposes ('.').
In the majority of crashes that I saw were in an area where rapid allocations and frees happened, this was due to the code that I used for the encryption. I'm wondering if I can save on the context allocations and frees in the future.

So I mailed Otto who gave me some helpful hints and having looked at his malloc code I was able to piece together what could have happened. If another network looks up for '.' it causes a 1 byte allocation to occur, the length is saved in a struct and a NUL byte is put in that 1 byte. This is the represent ation of the root zone. It's a hack because it really is 0 length. So then I have a second allocation for the human readable representation of the root zone which will be 2 bytes for the '.' and the NUL terminator (it's a string). The problem I found in the function convert_name() which is supposed to short circuit the root zone and return a length of 2. Unfortunately I had a wrong check in this function that checked for a NUL byte on the 1st element (starting at zeroth), which was a bug, it should check the zeroth element. I was able to track down this commit done in 2020 . So what is there to know? And how does this bug occur? I suspect that build_question() built the root question name with one byte and one byte length and then freed it. Whenever a free occurs Otto's malloc writes a magic called deadfree's (0xdfdfdfdfdfdfdfdf) which account for 8 bytes over the freed area. The actual freeing is delayed until next free actually which gives the code a chance to detect 'write after free\'s'. Once the chunk is freed another one byte allocation comes along and sets NUL byte, but the adjacent bytes are still from the freeing so 0x00dfdfdfdfdfdfdf. At this point when the convert_name() is called the bug is that the short circuit fails and the rest falls through due to passing 0 to memcpy (which too is erroneous). The 2 byte allocation will then be zero filled (2 NUL's) makeing the human representation flawed. This would reflect on the logs most likely. There is a cascading effect taking off for this NUL, NUL in fact turning into just a NUL in the (so-called) engine process.

If this isn't the bug, then it's one of many. I also made sure I 8 byte aligned the shared memory slot for struct parsequestion. So far looking at it the code has held up longer than other times. I'll be backporting the fixes for this into the 1.7.3 release. Good night!

0 comments

Delphinusdnsd 1.7.2 released

March 22nd, 2023

Today I finished the code to the new txt parsing, and backported it to the STABLE_1_7 branch. This addresses the problems I identified on this blog on December 25th, 2022 and explained it a little more on January 3rd. I'm happy I found time to do this as this month I had lots of appointments for non-coding related things. Please enjoy this change!

0 comments

False alert, code refactored anyhow

March 08th, 2023

I made a mistake there was no buffer overflow. There was 5 variables to watch and a buffer which was 0xffff + 3 bytes big. The one variable I did not watch close enough was tcpnp->bytes_expected, which limits how much can be read and is decreased. I'm sorry for the heartthrob, I won't backport the refactored code just yet.

0 comments

Potential buffer overflow on the heap, please upgrade

March 8th, 2023

I have found a potential buffer overflow in the TCP and TLS code. I think the TCP code was around for a number of years. Since June 2019 at least. The best way to go about this is to upgrade to the master branch with git and recompile. Then wait for a 1.7.2 patch release, the code hasn't changed much since 1.7.1 and thus this is OK.

0 comments

AXFR (for primary) needs to be re-written

January 31st, 2023

The quest to give the source of a notify packet a bound IP had me going off on a trail to fix it. However..., I have realised I need to rewrite this code partially. It was first implemented in the predecessor of delphinusdnsd under the wildcarddnsd name. This was in 2011 and before I moved into this nice apartment. I don't really know what I was on (self admittance). So I'm going to adjust the TODO file accordingly and plan out this code. Important to me is, that this code is readable, and not jammed. As in that you cannot really move it forwards or backwards and gain what you want from it. This takes time out of my day unfortunately that I would otherwise use to relax. Maybe a bit of work is good for me though.

0 comments

Preventing Burn-out

January 30th, 2023

The TODO's for this year will likely not be achieved. The usage of delphinusdnsd will have to be watched by me and some parts will have to be rewritten as they are just impossible to maintain. This means that this year there will likely not be a dns update functionality. I'm not saying this in spite but rather want to prevent a burn out of myself. I deserve a break and if anyone wants to contribute the best way is to send me patches first before we both consider adding you to the commit list.

Also there have been some breakthroughs with the got (game of trees) program that I might make use of. This may mean that I'm possibly taking development from github back to a got repo. However. Since we're on version 1.7.1 now and the last release will be before 2.0.0 for me this may not happen. It's something to consider though. Eventually I'll have to let go graciously.

0 comments

TODO's building up

January 28th, 2023

I found another issue with delphinusdnsd as an AXFR primary. When on a host with IP aliases it will sometimes pick the wrong IP (IPv6). I have a patch but it does wrong things which I have to debug first before I commit it. The TXT RR problem is also by now on the back burner, the emotional blockage that I have hasn't fully healed and I lack the concentration to sit down and do this right now. If anyone wants to step up and help that would be grand. If not, it will take its natural time.

0 comments