Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG  Not logged in ELOG logo
icon5.gif   Path disclosure on unfound file, posted by Bruce Bush on Wed May 6 17:35:14 2015 
    icon2.gif   Re: Path disclosure on unfound file, posted by Stefan Ritt on Wed Jun 10 09:12:06 2015 Screen_Shot_2015-06-10_at_9.11.38_.png
       icon2.gif   Re: Path disclosure on unfound file, posted by Travis Unkel on Fri Aug 18 01:02:41 2017 
          icon2.gif   Re: Path disclosure on unfound file, posted by prinnydood on Thu Dec 31 18:35:19 2020 no_extension.pngnonexistent_html.pngrandom_extension.pngvalid_html_file_with_html_extension.png
             icon2.gif   Re: Path disclosure on unfound file, posted by Stefan Ritt on Fri Jan 8 13:47:14 2021 Screenshot_2021-01-08_at_13.46.02_.png
                icon2.gif   Re: Path disclosure on unfound file, posted by Gabriel Lopez on Wed Feb 3 17:28:16 2021 
                   icon2.gif   Re: Path disclosure on unfound file, posted by Stefan Ritt on Fri Feb 19 09:59:04 2021 
                      icon2.gif   Re: Path disclosure on unfound file, posted by Gabriel Lopez on Fri Feb 19 19:48:11 2021 
Message ID: 69306     Entry time: Fri Feb 19 19:48:11 2021     In reply to: 69305
Icon: Reply  Author: Gabriel Lopez  Author Email: gabelopez@bnl.gov 
Category: Bug report  OS: Linux  ELOG Version: 3.1.4 
Subject: Re: Path disclosure on unfound file 

Thank you for your work. Works like a charm!

Stefan Ritt wrote:

I made a new RPM: https://elog.psi.ch/elog/download/RPMS/elog-3.1.4-3.el7.x86_64.rpm

Gabriel Lopez wrote:

Hello, This is coming up as a high vulnerability in our scans. Are there plans to update the rpm for this fix? If so is there an ETA? Any update would be much appreciated. Currently running elog-3.1.4-2 

Stefan Ritt wrote:

Ok, I fixed the code in the current commit (395e101add19f0fe8a11a25d0822e511f34d94d1). The path gets stripped, and we see a

prinnydood wrote:

I can confirm this issue exists on version 3.1.3, which I have installed elog on Debian 10.

The issue also exists on version 3.14 (1.20190113git283534d97d5a.el7), which I tested on an AmazonLinux EC2 instance.

This is what I found:

1. if I leave out the extension at the end of the URL for a non-existent page, it gives me the red error box. So far so good... Example: /gibberish

2. if I include any random extension at the end of the URL for a non-existent page, it gives me the red error box. So far so good... Example: /gibberish.php or /gibberish.htm or /gibberish.asdfasd

3. if I include any .html extension specifically at the end of the URL for a non-existent page, elog exposes the path /usr/share/elog/themes/default/gibberish.html. This is a bug... Example: /gibberish.html exposes the path, and likewise, /.gibberish.html ( "dot" + gibberish) exposes the path

4. if I include a valid, existent .html file which is located in the directory /usr/share/elog/themes/default/, and call it, elog exposes the html document. Example: I created an html file called gibberish.html (containing <html><body><p>Hello world</p></body></html>) in my system's /usr/share/elog/themes/default/ directory. After navigating back to the /gibberish.html URL, I was presented with the HTML file.

Turning on -v (verbose mode), the response by elogd when accessing these are: "GET /elog/gibberish.html HTTP/1.0 Returned 605 bytes" (displays "Hello world" html file), and "GET /elog/gibberish.asdfasd HTTP/1.0 Returned 605 bytes" (displays red error box).

=====

My guess: the program seems to be caring about the files ONLY if they have html file extension. Please see the screenshots below.

====

What are the security implications? Not much, I think. From what I can tell, exposing the "/usr/share/themes/elog" path, and also exposing the elog version when the file does not exist. Hope this reply helps anyone else with the same question.

(I am sure the error exposing the version can be removed by editing the source code--this is probably beyond my capabilities at this point).

 

 

 

 

ELOG V3.1.5-3fb85fa6