export/archive a logbook, posted by Jacky Li on Thu Feb 18 19:21:57 2021
|
Hi,
I have an elogd server serves many logbooks. May I know what is a good way to export or achive one its logbooks? Thank you.
Jacky |
Re: export/archive a logbook, posted by Stefan Ritt on Fri Feb 19 08:35:53 2021
|
Find -> Export to: CSV (or any other format) -> Search
| Jacky Li wrote: |
|
Hi,
I have an elogd server serves many logbooks. May I know what is a good way to export or achive one its logbooks? Thank you.
Jacky
|
|
|
Re: Path disclosure on unfound file, posted by Stefan Ritt on Fri Feb 19 09:59:04 2021
|
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).
|
|
|
|
|
Re: Path disclosure on unfound file, posted by Gabriel Lopez on Fri Feb 19 19:48:11 2021
|
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).
|
|
|
|
|
Additional forbidden attributes, posted by Sebastian Schenk on Mon Jun 14 16:15:10 2021
|
Hello Stefan,
I stubbled on a issue with our elog.
We introduced an attribute "mode" to one of the elogs and it breaks the "Find" function as this attribute is already used for the viewing settings "full", "summary" and "threaded".
(HTTP parameter pollution)
I suspect other special attributes used by the internals of elog should also not be allowed.
A quick search in the "Find" reveals these attributes in the URL, so I guess, these should also be avoided.
This list could be incomplete
npp, ma, da, ya, mb, db, yb, attach, reverse, mode
A simple workaround would be updating the documentation to add these to the list of forbidden attributes.
https://elog.psi.ch/elog/config.html
Maybe a warning can be added, if the elog behaves unexpected, try other attribute names, as they can conflict with internal attributes.
A fix could be to add a prefix for internal attributes, which can't be used for user attributes.
Best wishes,
Sebastian
PS: I also noticed using the "Find" command, the generated URL contains 2 reverse attributes like "reverse=0&reverse=1" |
|
Deny option and Guest commands, posted by Janusz Szuba on Mon Jul 19 18:41:29 2021
|
Hi,
I have a logbook with guest access and guest can also enter a new entry (in config: Guest List Menu commands = New, Find, Select, Login). For other reason in a global section, I put
Deny New = account1, account2
This somehow invalidates Guest List Menu commands, since as guest I don't see New button anymore. Is this behaviour desired? Otherwise, I would need to move Deny option to plenty of individual logbook configs. Just to explain the reason, those accounts are set up to only read entries and not to create new ones. Or maybe you can suggest a different solution?
Best |
|
Logging Main page entries, each with multiple ongoing events , posted by Alan Grant on Wed Jul 21 16:16:29 2021
|
Is there any way to log child events on the detail pages for a fixed number of entries on the main page? For example, I have 15 vehicles to enter on the main page, ID'd by Vehicle Number. Within each of those entries I will be logging ongoing repair service entries with certain attributes.
So how might I design this concept without having repeating vehicle entries on the main page for every service event, and preferably without splitting the information between two linked logbook tabs?
|
|
Large log file size, posted by Alan Grant on Mon Aug 30 03:08:15 2021
|
Can the size of the application log file affect performance? |
|