Bug 37080 -- StrToHostAddr accepts all Pascal number notations

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug 37080 -- StrToHostAddr accepts all Pascal number notations

Free Pascal - General mailing list
While doing some work on bug 37060, the refactoring of StrToHostAddr and
StrToHostAddr6 in the sockets
unit,(https://bugs.freepascal.org/view.php?id=37060), I found that
StrToHostAddr is doing no validation at all on input address characters
before calling the function Val, so any Pascal notation that Val
accepts, such as 0x and $ for hexadecimal, % for binary, & for octal,
and mathematical signs are all accepted in ipv4 octets.

https://bugs.freepascal.org/view.php?id=37080

As a consequence, StrToHostAddr will happily parse addresses like these:

0xa.3.4.5
9.$c.4.5
%1111.%11001110.30.4
&7.&5.30.4
12.+4.1.1

Any number in any notation will be accepted as long as byte overflow
isn't triggered. Thus, + in octets is accepted, but - is not, because
the function detects that the octet is negative which then triggers
overflow.

Fixing this is outside the scope of the patch I'm preparing for 37060,
but if no-one else feels inclined to look into this by the time I'm
finished with that patch then I'll submit a new patch for it.



_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug 37080 -- StrToHostAddr accepts all Pascal number notations

Michael Van Canneyt


On Fri, 15 May 2020, Noel Duffy via fpc-pascal wrote:

> While doing some work on bug 37060, the refactoring of StrToHostAddr and
> StrToHostAddr6 in the sockets
> unit,(https://bugs.freepascal.org/view.php?id=37060), I found that
> StrToHostAddr is doing no validation at all on input address characters
> before calling the function Val, so any Pascal notation that Val
> accepts, such as 0x and $ for hexadecimal, % for binary, & for octal,
> and mathematical signs are all accepted in ipv4 octets.
>
> https://bugs.freepascal.org/view.php?id=37080
>
> As a consequence, StrToHostAddr will happily parse addresses like these:
>
> 0xa.3.4.5
> 9.$c.4.5
> %1111.%11001110.30.4
> &7.&5.30.4
> 12.+4.1.1
>
> Any number in any notation will be accepted as long as byte overflow
> isn't triggered. Thus, + in octets is accepted, but - is not, because
> the function detects that the octet is negative which then triggers
> overflow.
>
> Fixing this is outside the scope of the patch I'm preparing for 37060,
> but if no-one else feels inclined to look into this by the time I'm
> finished with that patch then I'll submit a new patch for it.

Fixed.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug 37080 -- StrToHostAddr accepts all Pascal number notations

Free Pascal - General mailing list
On 15/05/20 10:48 pm, Michael Van Canneyt wrote:

>
>
> On Fri, 15 May 2020, Noel Duffy via fpc-pascal wrote:
>
>> While doing some work on bug 37060, the refactoring of StrToHostAddr
>> and StrToHostAddr6 in the sockets
>> unit,(https://bugs.freepascal.org/view.php?id=37060), I found that
>> StrToHostAddr is doing no validation at all on input address
>> characters before calling the function Val, so any Pascal notation
>> that Val accepts, such as 0x and $ for hexadecimal, % for binary, &
>> for octal, and mathematical signs are all accepted in ipv4 octets.
>>
>> https://bugs.freepascal.org/view.php?id=37080
>>
>> As a consequence, StrToHostAddr will happily parse addresses like these:
>>
>> 0xa.3.4.5
>> 9.$c.4.5
>> %1111.%11001110.30.4
>> &7.&5.30.4
>> 12.+4.1.1
>>
>> Any number in any notation will be accepted as long as byte overflow
>> isn't triggered. Thus, + in octets is accepted, but - is not, because
>> the function detects that the octet is negative which then triggers
>> overflow.
>>
>> Fixing this is outside the scope of the patch I'm preparing for 37060,
>> but if no-one else feels inclined to look into this by the time I'm
>> finished with that patch then I'll submit a new patch for it.
>
> Fixed.

That must be a new record in bug fix speed. You fixed that within ten
minutes of my message to the list!

I forgot to mention in my message, but did mention in the bug report,
that leading zeroes are also allowed, so you can parse:

0000000001.1.1.1



_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug 37080 -- StrToHostAddr accepts all Pascal number notations

Michael Van Canneyt


On Fri, 15 May 2020, Noel Duffy via fpc-pascal wrote:

> That must be a new record in bug fix speed. You fixed that within ten
> minutes of my message to the list!
>
> I forgot to mention in my message, but did mention in the bug report,
> that leading zeroes are also allowed, so you can parse:
>
> 0000000001.1.1.1

Personally I don't think this is a problem (mathematically, you can add as
many zeroes as you like), but I can imagine some do,  so I fixed it.

Rev. 45368.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug 37080 -- StrToHostAddr accepts all Pascal number notations

Free Pascal - General mailing list
On 15/05/20 11:25 pm, Michael Van Canneyt wrote:

>
>
> On Fri, 15 May 2020, Noel Duffy via fpc-pascal wrote:
>
>> That must be a new record in bug fix speed. You fixed that within ten
>> minutes of my message to the list!
>>
>> I forgot to mention in my message, but did mention in the bug report,
>> that leading zeroes are also allowed, so you can parse:
>>
>> 0000000001.1.1.1
>
> Personally I don't think this is a problem (mathematically, you can add as
> many zeroes as you like), but I can imagine some do,  so I fixed it.

Well, the same argument could be made for allowing hexadecimal or other
notations. But ip address representation formats aren't just numbers,
they're textual representations meant for easy transmission between
programs and across networks, and the standards documents are quite
clear about what's allowed in them and what's not. If StrToHostAddr
breaks with those standards and accepts addresses that other
implementations won't, or rejects addresses others accept, that makes it
unusable for programs that must operate in mixed language environments.

In my own case, I'm writing a program to parse and validate SPF records,
as defined in RFC7208. SPF records are read and processed by SMTP
servers as they receive mail, so any tools that attempt to validate SPF
records must not accept as valid any ipv4 or ipv6 address that the SMTP
server won't also accept.


_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug 37080 -- StrToHostAddr accepts all Pascal number notations

Jonas Maebe-3
In reply to this post by Free Pascal - General mailing list
On 15/05/2020 12:39, Noel Duffy via fpc-pascal wrote:
> While doing some work on bug 37060, the refactoring of StrToHostAddr and
> StrToHostAddr6 in the sockets
> unit,(https://bugs.freepascal.org/view.php?id=37060), I found that
> StrToHostAddr is doing no validation at all on input address characters
> before calling the function Val, so any Pascal notation that Val
> accepts, such as 0x and $ for hexadecimal, % for binary, & for octal,
> and mathematical signs are all accepted in ipv4 octets.

I added a note to https://bugs.freepascal.org/view.php?id=37013 about
the fact that this test program fails if range checking is enabled (I
don't know if the range error is in StrToHostAddr6 or in the test
program itself).


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug 37080 -- StrToHostAddr accepts all Pascal number notations

Michael Van Canneyt


On Sat, 16 May 2020, Jonas Maebe wrote:

> On 15/05/2020 12:39, Noel Duffy via fpc-pascal wrote:
>> While doing some work on bug 37060, the refactoring of StrToHostAddr and
>> StrToHostAddr6 in the sockets
>> unit,(https://bugs.freepascal.org/view.php?id=37060), I found that
>> StrToHostAddr is doing no validation at all on input address characters
>> before calling the function Val, so any Pascal notation that Val
>> accepts, such as 0x and $ for hexadecimal, % for binary, & for octal,
>> and mathematical signs are all accepted in ipv4 octets.
>
> I added a note to https://bugs.freepascal.org/view.php?id=37013 about
> the fact that this test program fails if range checking is enabled (I
> don't know if the range error is in StrToHostAddr6 or in the test
> program itself).

I will check.
I never use range checking, so that could have easily escaped me.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug 37080 -- StrToHostAddr accepts all Pascal number notations

Michael Van Canneyt


On Sat, 16 May 2020, Michael Van Canneyt wrote:

>
>
> On Sat, 16 May 2020, Jonas Maebe wrote:
>
>> On 15/05/2020 12:39, Noel Duffy via fpc-pascal wrote:
>>> While doing some work on bug 37060, the refactoring of StrToHostAddr and
>>> StrToHostAddr6 in the sockets
>>> unit,(https://bugs.freepascal.org/view.php?id=37060), I found that
>>> StrToHostAddr is doing no validation at all on input address characters
>>> before calling the function Val, so any Pascal notation that Val
>>> accepts, such as 0x and $ for hexadecimal, % for binary, & for octal,
>>> and mathematical signs are all accepted in ipv4 octets.
>>
>> I added a note to https://bugs.freepascal.org/view.php?id=37013 about
>> the fact that this test program fails if range checking is enabled (I
>> don't know if the range error is in StrToHostAddr6 or in the test
>> program itself).
>
> I will check.
> I never use range checking, so that could have easily escaped me.

Fixed 2 occurrences of a range check.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug 37080 -- StrToHostAddr accepts all Pascal number notations

Free Pascal - General mailing list
In reply to this post by Jonas Maebe-3
On 17/05/20 1:21 am, Jonas Maebe wrote:

> On 15/05/2020 12:39, Noel Duffy via fpc-pascal wrote:
>> While doing some work on bug 37060, the refactoring of StrToHostAddr and
>> StrToHostAddr6 in the sockets
>> unit,(https://bugs.freepascal.org/view.php?id=37060), I found that
>> StrToHostAddr is doing no validation at all on input address characters
>> before calling the function Val, so any Pascal notation that Val
>> accepts, such as 0x and $ for hexadecimal, % for binary, & for octal,
>> and mathematical signs are all accepted in ipv4 octets.
>
> I added a note to https://bugs.freepascal.org/view.php?id=37013 about
> the fact that this test program fails if range checking is enabled (I
> don't know if the range error is in StrToHostAddr6 or in the test
> program itself).

D'oh! Normally I'm scrupulous about turning on range checks in my own
programs, but I completely forgot to do that here. But I see Michael has
already fixed it.



_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug 37080 -- StrToHostAddr accepts all Pascal number notations

Free Pascal - General mailing list
In reply to this post by Michael Van Canneyt
On 17/05/20 3:00 am, Michael Van Canneyt wrote:

>
>
> On Sat, 16 May 2020, Michael Van Canneyt wrote:
>
>>
>>
>> On Sat, 16 May 2020, Jonas Maebe wrote:
>>
>>> On 15/05/2020 12:39, Noel Duffy via fpc-pascal wrote:
>>>> While doing some work on bug 37060, the refactoring of StrToHostAddr
>>>> and
>>>> StrToHostAddr6 in the sockets
>>>> unit,(https://bugs.freepascal.org/view.php?id=37060), I found that
>>>> StrToHostAddr is doing no validation at all on input address characters
>>>> before calling the function Val, so any Pascal notation that Val
>>>> accepts, such as 0x and $ for hexadecimal, % for binary, & for octal,
>>>> and mathematical signs are all accepted in ipv4 octets.
>>>
>>> I added a note to https://bugs.freepascal.org/view.php?id=37013 about
>>> the fact that this test program fails if range checking is enabled (I
>>> don't know if the range error is in StrToHostAddr6 or in the test
>>> program itself).
>>
>> I will check. I never use range checking, so that could have easily
>> escaped me.
>
> Fixed 2 occurrences of a range check.

Looking at the code  in SVN, I spotted a couple of still extant
references to s6_addr16 instead of u6_addr16 in StrToHostAddr6. It's
possible to trigger range check errors for them. All s6_addr16s should
be u6_addr16s.

If you try parsing an address like '::ffff' it will hit this part of the
code.

Sorry for the screw-up. Normally I religiously use range checks in my
own code, but it completely went out of my head when working on this.



_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug 37080 -- StrToHostAddr accepts all Pascal number notations

Michael Van Canneyt


On Sun, 17 May 2020, Noel Duffy via fpc-pascal wrote:

> On 17/05/20 3:00 am, Michael Van Canneyt wrote:
>>
>>
>> On Sat, 16 May 2020, Michael Van Canneyt wrote:
>>
>>>
>>>
>>> On Sat, 16 May 2020, Jonas Maebe wrote:
>>>
>>>> On 15/05/2020 12:39, Noel Duffy via fpc-pascal wrote:
>>>>> While doing some work on bug 37060, the refactoring of StrToHostAddr
>>>>> and
>>>>> StrToHostAddr6 in the sockets
>>>>> unit,(https://bugs.freepascal.org/view.php?id=37060), I found that
>>>>> StrToHostAddr is doing no validation at all on input address characters
>>>>> before calling the function Val, so any Pascal notation that Val
>>>>> accepts, such as 0x and $ for hexadecimal, % for binary, & for octal,
>>>>> and mathematical signs are all accepted in ipv4 octets.
>>>>
>>>> I added a note to https://bugs.freepascal.org/view.php?id=37013 about
>>>> the fact that this test program fails if range checking is enabled (I
>>>> don't know if the range error is in StrToHostAddr6 or in the test
>>>> program itself).
>>>
>>> I will check. I never use range checking, so that could have easily
>>> escaped me.
>>
>> Fixed 2 occurrences of a range check.
>
> Looking at the code  in SVN, I spotted a couple of still extant
> references to s6_addr16 instead of u6_addr16 in StrToHostAddr6. It's
> possible to trigger range check errors for them. All s6_addr16s should
> be u6_addr16s.
>
> If you try parsing an address like '::ffff' it will hit this part of the
> code.
>
> Sorry for the screw-up. Normally I religiously use range checks in my
> own code, but it completely went out of my head when working on this.

That's what you get when communication with someone who doesn't use them:
It's contagious ;-)

I'll have a look.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug 37080 -- StrToHostAddr accepts all Pascal number notations

Joost van der Sluis
In reply to this post by Michael Van Canneyt
Op 15-05-2020 om 12:48 schreef Michael Van Canneyt:

> On Fri, 15 May 2020, Noel Duffy via fpc-pascal wrote:
>> As a consequence, StrToHostAddr will happily parse addresses like these:
>>
>> 0xa.3.4.5
>> 9.$c.4.5
>> %1111.%11001110.30.4
>> &7.&5.30.4
>> 12.+4.1.1
>
> Fixed.

Ahh.. why.. 😢

An ip-address of 0xa.&5.%11001110.3 is just funny. 😀

Regards,

Joost.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal