This also means that if Solr is reachable from the outside via reverse proxy (this should never happen btw) the issue can be mitigated by configuring the reverse proxy with the internal network Solr hostname instead of the internal network ip address.
On Fri, Apr 8, 2022 at 8:42 AM Vincenzo D'Amore <v.dam...@gmail.com> wrote: > 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 > > -- Vincenzo D'Amore
