OpenBSD Journal

n2k15: tedu@ on rebound, malloc hardening, removing legacy code

Contributed by tj on from the you-saw-the-axe dept.

The second n2k15 hackathon report comes from Ted Unangst (tedu@), who writes:

I don't usually get too involved with the network stack, but sometimes you find yourself at a network hackathon and have to go with the flow. With many developers working in the same area, it can be hard to find an appropriate project, but fortunately there are a few dusty corners in networking land that can be swept up without too much disturbance to others.
IPv6 is the future of networking. IPv6 has also been the future of networking for 20 years. As a result, a number of features have been proposed, implemented, then obsoleted, but the corresponding code never quite gets deleted. The IPsec stack has followed a somewhat similar trajectory.

I read through various networking headers in search of features that would normally be exposed to userland, but were instead guarded by ifdef _KERNEL. This identified a number of options for setsockopt() that had been officially retired from the API, but the kernel code retained to provide ABI compatibility during a transtion period. That transition occurred more than a decade ago. Binary programs from that era no longer run for many other reasons, and so we can delete support. It's only a small improvement, but it gradually reduces the amount of code that needs to be reviewed when making larger more important changes.

The ifconfig tool has a similar story. Long ago, it was possible to control transmission power for wireless devices. Presently, however, only the wi driver (a great driver in its day, but no longer relevant) supports this option. Trying to use the txpower command with a modern driver is likely to result in an error:

ifconfig: SIOCS80211TXPOWER: Invalid argument.

Some drivers, though, misleadingly claim to support this option. It's a knob you can turn, but it's not connected to the radio and has no effect. Better to remove it so that users are not confused and mislead into believing it does something.

Even longer ago, there was an option to support ethernet trailers. You can read RFC 893 for the details about how this enabled zero copy networking on a VAX with 512 byte hardware pages. This option was removed even before OpenBSD was founded, but nevertheless a fake option was left in ifconfig which printed a message. And a random assortment of drivers would set the NOTRAILERS flag, which ifconfig would dutifully support. But there is no behavioral difference to explain why rtw had this flag but urtw did not.

Returning to the present, I spent some time working on rebound. rebound is a simple DNS proxy meant to resolve some of the issues that occur with the current design of having every program directly query the network itself. I think it's nearing completion, but there are always more edge cases that need handling. For example, when one doesn't have any network configured, the libc resolver will immediately fail because the sendto() syscall will return an error. But when using a localhost proxy like rebound, that call will succeed, and rebound will experience the error. I initially treated all errors in rebound as transient. After all, UDP is lossy and I knew libc would retry after a timeout. But in this case, we don't want to retry after a timeout; we want to fail immediately to avoid long hangs. So now rebound detects this condition and responds with an empty packet to keep libc moving along.

I also looked at some diffs to malloc previously proposed by Daniel Micay which add a bit more integrity checking and use after free detection. We should be able to integrate these soon. And I continued some work leftover from the utf-8 hackathon. Ingo has taken over the coding efforts, so there's some good diffs to review and test. And it wouldn't be a hackathon if I didn't have to deal with at least one feature request for doas. :)

Thanks for the report! A legacy-free system is a happy system.

(Comments are closed)


Comments
  1. By Anonymous Coward (178.194.126.68) on

    Great post! Didn't find anything about malloc hardening though...

    Comments
    1. By brynet (Brynet) on http://brynet.biz.tm/

      > Great post! Didn't find anything about malloc hardening though...

      Last paragraph.

  2. By Ingo Schwarze (schwarze) schwarze@openbsd.org on mdocml.bsd.lv

    Nice report, just commenting on the most minor point (:

    > And I continued some work leftover from the utf-8 hackathon.
    > Ingo has taken over the coding efforts

    Hey, nobody should stop coding for UTF-8! I'm even more happy to review UTF-8 diffs from others than to get reviews for my own diffs. I can't do that all alone, there is so much to do... What i'm trying to make sure is that people get feedback and stuff committed when they work on it, that confusion is resolved and work coordinated. Sure, as always, i'll happily write some code too, but not all alone!

    > so there's some good diffs to review and test.

    Indeed, thanks for your testing and feedback, in addition to my thanks for the many ideas i poached from your earlier diffs...

    Comments
    1. By Anonymous Coward (77.6.102.106) on

      > Hey, nobody should stop coding for UTF-8! I'm even more happy to review UTF-8 diffs from others than to get reviews for my own diffs. I can't do that all alone, there is so much to do... What i'm trying to make sure is that people get feedback and stuff committed when they work on it, that confusion is resolved and work coordinated. Sure, as always, i'll happily write some code too, but not all alone!

      Thanks a lot, Ingo, for your efforts related to UTF-8 and for keeping up that topic! Even though u2k15 was meant to be a unicode hackathon, there was not too much information on unicode progress here on Undeadly if I remember correctly (network things, gpt, ports...). Would be very happy to read something about UTF-8 progress some time in the future.

  3. By Anonymous Coward (79.247.129.181) on

    I have some Questions related to rebound:

    What would be a use-case for rebound?!
    I Can't figure it out from the manpage.

    Why not simply using resolv.conf? (this is related to the previous Question, if it runs localy anyway)

    You wrote about UDP but DNS can get used via TCP as well.
    Is this also handled?!

    Comments
    1. By Ilyas Bakirov (5.251.42.243) on

      I suggest you to read http://www.tedunangst.com/flak/post/rebound-relationship-with-pledge about rebound

      Comments
      1. By Anonymous Coward (79.247.129.181) on

        > I suggest you to read http://www.tedunangst.com/flak/post/rebound-relationship-with-pledge about rebound
        >
        >

        Thank you very much! But...

        Even on the risk of getting insulted: I still don't understand the basic Issue this Daemon should resolve.

        Why should I use it? When? Are there any special situations?
        It seams to be a "stupid" (non parsing!) Daemon, so a simple Proxy...

        I could imagine it could be usefull if it inspects DNS requests and filters out "suspecfull" data (like too large TXT fields, implying a DNS tunnel maybe...).

        I wont start a flamewar but I don't understand the problem this daemon should resolve. It would be very kind if somebody (even with harsh words) might help me out to understand it...

        Why was this Daemon programmed and what should it resolve?! Where is the benefit?! :-(

        Comments
        1. By Anonymous Coward (92.40.249.101) on

          > Even on the risk of getting insulted: I still don't understand the basic Issue this Daemon should resolve.

          It allows tightening pledges for software that needs DNS lookup but doesn't need to open additional normal sockets after pledging (like tcpdump, or daemons handling incoming connections that want to do reverse DNS).

          Also it gives a common uid that can be used in pf rules to block direct port 53 connections from normal uids (block requests not going through "the normal channels")

          And it gives a base where additional filtering could be added later. It would be nice to have rules that allow only queues of certain domains, for example, to allow lookup of internal resources but deny external domains to prevent DNS based exfiltration.

          Comments
          1. By Peter J. Philipp (pjp) on http://centroid.eu

            > > Even on the risk of getting insulted: I still don't understand the basic Issue this Daemon should resolve.
            >
            > It allows tightening pledges for software that needs DNS lookup but doesn't need to open additional normal sockets after pledging (like tcpdump, or daemons handling incoming connections that want to do reverse DNS).
            >
            > Also it gives a common uid that can be used in pf rules to block direct port 53 connections from normal uids (block requests not going through "the normal channels")
            >
            > And it gives a base where additional filtering could be added later. It would be nice to have rules that allow only queues of certain domains, for example, to allow lookup of internal resources but deny external domains to prevent DNS based exfiltration.

            If I may feature creep here...

            It would be cool if this program could do a number of tasks since it's already in-between resolver and res code. There is a mac os x program that I've heard about that is called little snitch which allows filtering control of DNS. This would be cool to have to extend it to the X Windowing system perhaps. For example you could have a whitelist of domain names and anything deviating from that first causes a pop-up on your X screen asking if you want to add it to the whitelist. It could also maintain a blacklist to maintain a state of a lookup without asking the user again if it should be blocked. I personally think it would give us some insights in DNSology that we may not have had before. I am a writer of an authoritative server, some of the logs I get emanating from my own workstations behind NAT to this server is sheer amazing and could be clamped down. Secondly it would be good if this program was used as an attempt to do DNSSEC validation so that the res code can be kept free of too complex code that needs to be linked in every program. Since I write DNS code as a hobby I may be able to help out with this program, if only looking for corrections. I should have more free time in the new year perhaps.

            Regards,

            -peter

        2. By Anonymous Coward (204.80.187.225) on

          > > I suggest you to read http://www.tedunangst.com/flak/post/rebound-relationship-with-pledge about rebound
          > >
          > >
          >
          > Thank you very much! But...
          >
          > Even on the risk of getting insulted: I still don't understand the basic Issue this Daemon should resolve.
          >
          > Why should I use it? When? Are there any special situations?
          > It seams to be a "stupid" (non parsing!) Daemon, so a simple Proxy...
          >

          That's exactly it, a simple proxy. With no DNS parsing, there is less attack surface.

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]