Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 376 of 808  Not logged in ELOG logo
 Find |  Login |  Help 
 Full | Summary | Threaded | Hide attachments  Show only new entries    6457 Entries 
Goto page Previous  1, 2, 3 ... 375, 376, 377 ... 806, 807, 808   Next  
ID Date Icon Author Author Email Category OS ELOG Version Subjectdown
  69299   Wed Feb 3 17:28:16 2021 Reply Gabriel Lopezgabelopez@bnl.govBug reportLinux3.1.4Re: Path disclosure on unfound file

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).

 

 

  69305   Fri Feb 19 09:59:04 2021 Reply Stefan Rittstefan.ritt@psi.chBug reportLinux3.1.4Re: Path disclosure on unfound file

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).

 

 

 

  69306   Fri Feb 19 19:48:11 2021 Reply Gabriel Lopezgabelopez@bnl.govBug reportLinux3.1.4Re: 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).

 

 

 

 

  68042   Tue Jul 14 19:12:55 2015 Reply Stefan Rittstefan.ritt@psi.chQuestionLinux3.1.0Re: Pasting pictures from clipboard does not work anymore (firefox 39)

I'm not aware of any workaround, so you might ask the author. Once you find a solution, I'm happy to include it in the distribution.

Stefan

Jan Henry Hetzel wrote:
Hallo, as I have already written in the title, my problem is that after uprgrading my firefox to version 39 I cannot include pictures from clipboard. A downgrade to a previous version of firefox helped. But as this is not recommended I wanted to ask if there is a workaround or if I should inform the author of the "imagepaste"-extension of the CKEditor? Best regards, Jan

 

  68057   Thu Jul 23 08:19:38 2015 Agree Jan Henry Hetzelj.hetzel@fz-juelich.deInfoLinux3.1.0Re: Pasting pictures from clipboard does not work anymore (firefox 39)

Hi,

following the author of imagepaste one should upgrade the version of th CKEditor to a version >= 4.5. So replacing the folder ckeditor with a new version helped.

Best,

Jan

Stefan Ritt wrote:

I'm not aware of any workaround, so you might ask the author. Once you find a solution, I'm happy to include it in the distribution.

Stefan

Jan Henry Hetzel wrote:
Hallo, as I have already written in the title, my problem is that after uprgrading my firefox to version 39 I cannot include pictures from clipboard. A downgrade to a previous version of firefox helped. But as this is not recommended I wanted to ask if there is a workaround or if I should inform the author of the "imagepaste"-extension of the CKEditor? Best regards, Jan

 

 

  68059   Wed Jul 29 11:53:13 2015 Reply Stefan Rittstefan.ritt@psi.chInfoLinux3.1.0Re: Pasting pictures from clipboard does not work anymore (firefox 39)

I updated the current version with this change (CKEditor 4.5.1) and indeed it fixes the problem. The change is comitted to the git repository and will be contained in the next release.

Jan Henry Hetzel wrote:

Hi,

following the author of imagepaste one should upgrade the version of th CKEditor to a version >= 4.5. So replacing the folder ckeditor with a new version helped.

Best,

Jan

Stefan Ritt wrote:

I'm not aware of any workaround, so you might ask the author. Once you find a solution, I'm happy to include it in the distribution.

Stefan

Jan Henry Hetzel wrote:
Hallo, as I have already written in the title, my problem is that after uprgrading my firefox to version 39 I cannot include pictures from clipboard. A downgrade to a previous version of firefox helped. But as this is not recommended I wanted to ask if there is a workaround or if I should inform the author of the "imagepaste"-extension of the CKEditor? Best regards, Jan

 

 

 

  68185   Tue Nov 10 14:08:47 2015 Reply Stefan Rittstefan.ritt@psi.chBug reportLinuxV3.1.1-b4dRe: Paste figure from Clipboard, CKEditor 4.5.1 and Firefox 42

That seems a CKEditor problem. Can you see if it works on their site (ckeditor.com). The current version is 4.5.4. Maybe they fixed it. You can upgrade CKEditor yourself in elog by just copying the new verson over the old /elog/scripts/ckeditor directory.

Simon Däster wrote:

I tried to paste an Image from Clipboard into the CKEditor 4.5.1. Unfortunatelly, that doesn't work. I used Firefox, version 42. When I  looked in the javascript error console, it reported that "TypeError: b is undefined, ckeditor.js:1139:112". The variable  d.config.filebrowserImageUploadUrl could not be found.

I set the variable in the file ckeditor-config.js in the folder scripts, but that didn't solve the problem. As far as I can tell, Pasting Image from Clipboard does not work in this forum neither, but I don't know whether this is in purpose.

Pasting via the button "Paste from Word" works as it inserts a 64base formated image, but that's not what I'm searching for. Also normal upload of files works fine and puts the file in the correct folder (logbook/year/)

 

 

 

  68200   Mon Nov 23 10:32:37 2015 Reply Simon Dästerdaesters@phys.ethz.chBug reportLinuxV3.1.1-b4dRe: Paste figure from Clipboard, CKEditor 4.5.1 and Firefox 42

Updating CKeditor did work, thanks for the tip.

Goto page Previous  1, 2, 3 ... 375, 376, 377 ... 806, 807, 808   Next  
ELOG V3.1.5-3fb85fa6