dnsmasq reads the config file using `fgets` functions, so it depends on its
implementation. As far as i know, the default glibc supports only \n
character as a line delimiter

On Tue, Aug 17, 2021 at 6:41 PM Jeremy Stanley <email address hidden>
wrote:

> Naive question, but can the same bug be exploited with other characters
> besides linefeed? Maybe carriage returns (\r), form feeds (\f), or
> vertical tabs (\v) are treated similarly by dnsmasq?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1939733
>
> Title:
>   Remote Code Execution via extra_dhcp_opts
>
> Status in neutron:
>   New
> Status in OpenStack Security Advisory:
>   Incomplete
>
> Bug description:
>   This issue is being treated as a potential security risk under
>   embargo. Please do not make any public mention of embargoed
>   (private) security vulnerabilities before their coordinated
>   publication by the OpenStack Vulnerability Management Team in the
>   form of an official OpenStack Security Advisory. This includes
>   discussion of the bug or associated fixes in public forums such as
>   mailing lists, code review systems and bug trackers. Please also
>   avoid private disclosure to other individuals not already approved
>   for access to this information, and provide this same reminder to
>   those who are made aware of the issue prior to publication. All
>   discussion should remain confined to this private bug report, and
>   any proposed fixes should be added to the bug as attachments. This
>   embargo shall not extend past 2021-11-10 and will be made
>   public by or on that date even if no fix is identified.
>
>   Application doesnt check the input values for extra_dhcp_opts port
>   parameter allowing user to use a newline character. The values from
>   extra_dhcp_opts are used in rendering of opts file which is passed to
>   dnsmasq as a dhcp-optsfile. Considering this, an attacker can inject
>   any options to that file.
>
>   The main direct impact in my opinion is that attacker can push
>   arbitrary dhcp options to another instances connected to the same
>   network. And due to we are able to modify our own port connected to
>   external network, it is possible to push dhcp options to the instances
>   of another tennants using the same external network.
>
>   If we go further, there is an known buffer overflow vulnerability in
>   dnsmasq
>   (
> https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=7d04e17444793a840f98a0283968b96502b112dc
> )
>   which was not considered as a security issue due to attacker cannot
>   control dhcp opts in most cases and therefore this vulnerability is
>   still exists in most distributives (e.g Ubuntu 20.04.1). In our case
>   dhcp opts is exactly what attacker can modify, so we can trigger
>   buffer overflow there. I even managed to write an exploit which lead
>   to a remote code execution using this buffer overflow vulnerability.
>
>   Here the payload to crash dnsmasq as a proof of concept:
>   ```
>   PUT /v2.0/ports/9db67e0f-537c-494a-a655-c8a0c518d57e HTTP/1.1
>   Host: openstack
>   X-Auth-Token: TOKEN
>   Content-Type: application/json
>   Content-Length: 170
>
>   {"port":{
>   "extra_dhcp_opts":[{"opt_name":"zzz",
>
> "opt_value":"xxx\n128,aa:bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb\n120,aa.cc\n128,:"
>   }]}}
>   ```
>
>   Tested on ocata, train and victoria versions.
>
>   Vulnerability was found by Pavel Toporkov
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/neutron/+bug/1939733/+subscriptions
>
>