Malicious URL ? https://[::]/

[Roger Marquis]

Not necessarily BSD-related though this was discovered via a proxy
server jail's process table.

Source of the requests was a recently installed Firefox add-on. Not
sure how to escape the pattern for search engines but nothing is found
From queries wrapped in double quotes. The absense of previous log
entries or search results raises a number of questions. Is this
IPv6-related? Neither the client nor the proxy have IPv6 enabled. Is
it potentially malicious? If so by what mechanism?

The Intel IME backdoor vector is a primary suspect for obvious reasons
but am curious if anyone else has seen this?

Roger Marquis
_______________________________________________
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-securi...@freebsd.org"

[Dag-Erling Smørgrav]

Roger Marquis <mar...@roble.com> writes:
> Not necessarily BSD-related though this was discovered via a proxy
> server jail's process table.

Basically the IPv6 equivalent of https://127.0.0.1/. “[::]” is the
bracketed literal representation of the IPv6 localhost address.

DES
--
Dag-Erling Smørgrav - d...@des.no

[Dag-Erling Smørgrav]

Dag-Erling Smørgrav <d...@des.no> writes:
> Basically the IPv6 equivalent of https://127.0.0.1/. “[::]” is the
> bracketed literal representation of the IPv6 localhost address.

Hang on a sec — localhost should be [::1], not [::], which is the
equivalent of 0.0.0.0. My guess is a software bug. Jails look a little
weird from the inside unless you use a fully virtualized network stack.
The proxy probably doesn't have sufficient error checking around
getpeername() or something like that.

[Roger Marquis]

Dag-Erling Sm?rgrav wrote:
> Hang on a sec ? localhost should be [::1], not [::], which is the

> equivalent of 0.0.0.0. My guess is a software bug. Jails look a little
> weird from the inside unless you use a fully virtualized network stack.
> The proxy probably doesn't have sufficient error checking around
> getpeername() or something like that.

Another intermediate URL-checker reports that the plugin in question
(CanvasBlocker) is requesting https://[::]/ directly. If a bug this is
the first I've seen of it's kind. If not the question is what threat
profile [::]:443 might expose. (Other than the obvious jail vector
which really should be fixed. FreeBSD Foundation where are you?)

Karl's reference to RFC 4291 indicates it is a protocol violation as
well.

The symptom has been reported to Mozilla.

Roger

[Martin Simmons]

>>>>> On Wed, 24 Jan 2018 12:02:47 -0800 (PST), Roger Marquis said:
>
> Another intermediate URL-checker reports that the plugin in question
> (CanvasBlocker) is requesting https://[::]/ directly. If a bug this is
> the first I've seen of it's kind. If not the question is what threat
> profile [::]:443 might expose. (Other than the obvious jail vector
> which really should be fixed. FreeBSD Foundation where are you?)

Looks like expected behaviour for CanvasBlocker:

https://github.com/kkapsner/CanvasBlocker/issues/171

__Martin