Comment 7 for bug 1939733

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
>
>