I agree that a relative redirect without the ip/hostname of the server, and
not even the port should solve the security issue in a fairly simple way.
Just another thing I tried to do a couple of calls by myself:
curl -vv localhost:8983/
7 err
< HTTP/1.1 302 Found
< Location: http://localhost:8983/solr/
< Transfer-Encoding: chunked
curl -vv 127.0.0.1:8983/
ok
< HTTP/1.1 302 Found
< Location: http://127.0.0.1:8983/solr/
< Transfer-Encoding: chunked
As you can see the answer contains the ip/host of the caller.
On Fri, Apr 8, 2022 at 4:26 AM Gus Heck <gus.h...@gmail.com> wrote:
> 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)
>
--
Vincenzo D'Amore
