Are you assigning internal dns names to your solr servers? This possibly
will allow the redirect to use the internal dns name instead, likely
fooling the CVE checker program :) Just a thought on what to try if the
checker-runner folks are not understanding types.
As noted by the above folks, simple proxy or direct access to your solr
server from the outside is not good, don't do it. The auth/security
features are typically used for internal security. Disclosing the internal
IP to a checker running on an internal network is fundamentally not a risk,
because ANY computer on the internal network can look up the network
address based on a host name... that's what DNS is... So this would only
have meaning if the address crossed out of its home network. (at which
point mapping of the destination network from outsied is often considered a
security risk).
Finally, this redirect would not be a solr issue. It's Jetty code doing the
redirect based on
<!-- redirect root to solr -->
<Call name="addRule">
<Arg>
<New class="org.eclipse.jetty.rewrite.handler.RedirectRegexRule">
<Set name="regex">^/$</Set>
<Set name="location">/solr/</Set>
</New>
</Arg>
</Call>
-Gus
On Thu, Apr 7, 2022 at 7:53 PM dmitri maziuk <dmitri.maz...@gmail.com>
wrote:
> On 2022-04-07 6:18 PM, matthew sporleder wrote:
> > Yes I agree the point of the "vulnerability" is that an http 1.0 request
> (does not require a Host header) will cause the origin to guess what it
> should put in the Location header. In some cases that guess is the ip of
> the server. In an http 1.1 or higher request the host header is used.
> >
> > I don't know what it has to do with IIS or Basic auth but that cve is
> very very old.
> >
> > I can't think of a way to return a redirect without violating this
> condition because iirc the http spec says Location headers need to be fully
> qualified with protocol and host! That might not have applied in the http
> 1.0 days though. (Although in practice many servers return just /paths)
>
> I think you can redirect to either absolute or relative URL, the problem
> is that relative URLs are really just paths within DocumentRoot -- no
> port number. I.e. you can't use them to redirect from :80 to :8983.
>
> I'm not sure what that CVE is really about either, there's just not
> enough detail there to make any sense. Authentication's kinda b0rk3d in
> IIS anyway; AFAIK auth returns a 401, not a redirect. Whereas a redirect
> to IP is perfectly fine when, as you say, server can't figure out what
> name to put in there. The "iformation disclosure" problem sounds like it
> came out of the knee-jerk security research team since if the host is
> reachable, then its IP address is known...
>
> Dima
>
--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
