TXT entry with character combination creates invalid char about namedmanager HOT 7 OPEN

I found the bug, although I'm still left a bit confused. The issue is in htdocs/include/application/inc_domain.php, here:

// TXT string could be almost anything, just make sure it's quoted.
$data_tmp[$i]["content"] = str_replace("'", "", $data_tmp[$i]["content"]);
$data_tmp[$i]["content"] = str_replace('"', "", $data_tmp[$i]["content"]);

$data_tmp[$i]["content"] = '\\"'. $data_tmp[$i]["content"] .'\\"';

This code strips single and double quotes, then wraps the whole string in double quotes. There are a couple problem's with this, but the immediate issue is that if you enter this section of code with this string: \"torpedo\" then what you get out is "\torpedo\", the \t is then interpreted as a tab.

Also interesting, it seems that TXT records pass through this code twice before they get committed, so a string of torpedo is changed to "torpedo", then \"torpedo\" and then "\torpedo\".

Since we're screwing around with punctuation anyway, we could go a bit further and just strip and replace the slashes too, replace the third line (that re-quotes the string) with these two:

$data_tmp[$i]["content"] = str_replace('\\', "", $data_tmp[$i]["content"]);
$data_tmp[$i]["content"] = '\\"'. $data_tmp[$i]["content"] .'\\"';

I'm actually not sure that we even need to add the slashes back either, it may be enough to simply strip the \ and let the existing validation logic take care of it. I'm unclear of the expectations later in the code, but nothing obvious breaks either way.

This is still not completely correct as we are silently dropping all single quotes (which are permitted) and double quotes (which are permitted if escaped), but it is better than nothing.

from namedmanager.

Unfortunately we´re running into the same issue using let´s encrypt dns-01 authentication method, which is based on TXT records. And, it doesn´t matter if the record gets created via Web-UI or SOAP. Due to this, our setup sometimes runs into unexpected situations where affected dns-zones don´t get built :-/

We figured out that this issue happens in case of certain starting caracters like b, t, r, Z (capital). Trying to insert similar records "by hand" into the table dns_records works without any problems. Reloading the zone Web-UI shows those records correctly. After "submitting the form" without any changes, the records appear broken in the database. Seems to be an encoding-related bug?

We´re running namedmanager 1.9.0 within a LXD container on debian9 on top of php-fpm 7.0 and mariadb 10.1.26 with nginx as reverse proxy. We assume all of these components are "utf8 enabled"

Developer related help would be appreciated ;)

Thanks in advance...

from namedmanager.

I found the bug, although I'm still left a bit confused. The issue is in htdocs/include/application/inc_domain.php, here:

// TXT string could be almost anything, just make sure it's quoted.
$data_tmp[$i]["content"] = str_replace("'", "", $data_tmp[$i]["content"]);
$data_tmp[$i]["content"] = str_replace('"', "", $data_tmp[$i]["content"]);

$data_tmp[$i]["content"] = '\\"'. $data_tmp[$i]["content"] .'\\"';

This code strips single and double quotes, then wraps the whole string in double quotes. There are a couple problem's with this, but the immediate issue is that if you enter this section of code with this string: \"torpedo\" then what you get out is "\torpedo\", the \t is then interpreted as a tab.

Also interesting, it seems that TXT records pass through this code twice before they get committed, so a string of torpedo is changed to "torpedo", then \"torpedo\" and then "\torpedo\".

Since we're screwing around with punctuation anyway, we could go a bit further and just strip and replace the slashes too, replace the third line (that re-quotes the string) with these two:

$data_tmp[$i]["content"] = str_replace('\\', "", $data_tmp[$i]["content"]);
$data_tmp[$i]["content"] = '\\"'. $data_tmp[$i]["content"] .'\\"';

I'm actually not sure that we even need to add the slashes back either, it may be enough to simply strip the \ and let the existing validation logic take care of it. I'm unclear of the expectations later in the code, but nothing obvious breaks either way.

This is still not completely correct as we are silently dropping all single quotes (which are permitted) and double quotes (which are permitted if escaped), but it is better than nothing.

From my POV this issue is solved. Tested TXT-input with special characters from http://php.net/manual/en/language.types.string.php#language.types.string.syntax.double

@thedaveCA: thank you very much for your help! Are you planing to place a PR for this?

from namedmanager.

Is it sufficient to just strip the slashes? Or do we need to manually add them back when the quotes are re-added at the end?

from namedmanager.

why not letting PHP quote: http://php.net/manual/en/function.quotemeta.php?

from namedmanager.

sorry, wrong link: http://php.net/manual/en/function.addslashes.php

from namedmanager.

This is where my understanding of namedmanager's expected data format is lacking.

In the resulting zonefile we want TXT records to have double quotes around the content, but I'm not sure whether the records in the database need to be quoted or escaped and/or whether there is logic in the zonefile writer to add/fix quotes.

My personal preference would be to store data in the database already perfectly formed to be written to the zonefile as this reduces the odds of any ambiguity as to what the output will be. But I'm not sure about the current expectations.

from namedmanager.