Diagnostic tool can be used to kill the UDP listener

[webprofusion-chrisc]

Hi, so without specifying too much detail yet, I can use a standard tool to test my DNS server which in turn causes a buffer overrun which by default will cause the listener to throw an exception and stop responding.

Should I report the details somewhere specific? I haven't investigated a fix yet as this is just a prototype I'm working on.

Perhaps there is a standard way (in this library) to just catch this and continue?

Example exception (server created with dns2.createUDPServer):

internal/buffer.js:81
    throw new ERR_BUFFER_OUT_OF_BOUNDS();
    ^

RangeError [ERR_BUFFER_OUT_OF_BOUNDS]: Attempt to access memory outside buffer bounds
    at boundsError (internal/buffer.js:81:11)
    at Uint8Array.readUInt8 (internal/buffer.js:249:5)
    at Function.BufferReader.read (dns-service\node_modules\dns2\lib\reader.js:39:23)
    at BufferReader.read (dns-service\node_modules\dns2\lib\reader.js:49:26)
    at Function.Packet.Header.parse (dns-service\node_modules\dns2\packet.js:200:27)
    at Function.Packet.parse (dns-service\node_modules\dns2\packet.js:116:33)
    at Server.handle (dns-service\node_modules\dns2\server\udp.js:22:28)
    at Server.emit (events.js:315:20)
    at UDP.onMessage [as onmessage] (dgram.js:919:8) {
  code: 'ERR_BUFFER_OUT_OF_BOUNDS'

[webprofusion-chrisc]

Note that this appears to be possible to (naively) handle by adding a try..catch to https://github.com/song940/node-dns/blob/master/server/udp.js#L21

I have no idea if just not handling the message has and adverse effect elsewhere.

  handle(data, rinfo) {
    try {
      const message = Packet.parse(data);
      this.emit('request', message, this.response.bind(this, rinfo), rinfo);
    } catch { }
  }

[lsongdev]

Hi, @webprofusion-chrisc , what “Diagnostic tool” you are used？

Give me some information about dns client request details like dig command line arguments or wireshark packets.

[webprofusion-chrisc]

Hi, I wasn't sure if this represented a denial of service vulnerability which is why I was being vague.

It nmap using the DNS fuzz script: https://nmap.org/nsedoc/scripts/dns-fuzz.html

I think the issue is the message size is smaller than expected but it gets parsed anyway, so we run out of buffer to read.

[Aviv1000]

i have the same problem with this error

[risharde]

Subscribing in since this sounds like it needs to be fixed

[asampal]

This would be a great concern for me as well.

[pimterry]

Fixed in #57