bug in easyfind secret key decryption
Posted: 19 Oct 2014, 05:55
Hi
I noticed that my easyfind never really worked, and now that I have the code I managed to find out why. Problem was that the easyfind code takes the mac address and a unique key from the B23 to validate that the machine is indeed aB23. Problem however is that this input is sanitized using urldecode($_POST['key']). The function urldecode takes the HTML formatted (%2B) strings from the HTML GET command and converts them back to ASCII. But not all codes. In my case, my key had a '+' sign, which was converted to space. This wouldn't be a problem if all the interactions were using this same encodeing.However because the B23 sometimes uses HTTP_POST (not encoded) and sometime HTTP_GET (encoded), there is two records for my machine, one with a NULL pointer to the DNS table. The presence of two records (whereas there should be one) result in a premature script end when an update is encountered.
Solution: I changed the line that uses urldecode() to use rawurldecode(). This latter function does not replace '+' to ' ', but should otherwise have identical behaviour. I'll keep on looking for weird errors in the easyfind log but if anyone notices deprecation in the easyfind behaviour please let us know
I noticed that my easyfind never really worked, and now that I have the code I managed to find out why. Problem was that the easyfind code takes the mac address and a unique key from the B23 to validate that the machine is indeed aB23. Problem however is that this input is sanitized using urldecode($_POST['key']). The function urldecode takes the HTML formatted (%2B) strings from the HTML GET command and converts them back to ASCII. But not all codes. In my case, my key had a '+' sign, which was converted to space. This wouldn't be a problem if all the interactions were using this same encodeing.However because the B23 sometimes uses HTTP_POST (not encoded) and sometime HTTP_GET (encoded), there is two records for my machine, one with a NULL pointer to the DNS table. The presence of two records (whereas there should be one) result in a premature script end when an update is encountered.
Solution: I changed the line that uses urldecode() to use rawurldecode(). This latter function does not replace '+' to ' ', but should otherwise have identical behaviour. I'll keep on looking for weird errors in the easyfind log but if anyone notices deprecation in the easyfind behaviour please let us know