| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
69481
|
Wed Mar 2 23:15:11 2022 |
 | Konstantin Olchanski | olchansk@triumf.ca | Bug report | Linux | ELOG V3.1.4-cb3 | Re: Invalid activation code |
> Something is not right with the elog account activation...
I did a test:
- register as new user "test", web page says "request for approval sent..." (good)
- check elog config, user "test" is present, "active" set to "no" (good)
- open the "approve/activate" URL, get "Invalid activation code" (should say: "activated successfully!")
- check elog config, user "test" now has "active" set to "yes" (good, "approve/activate" URL worked)
- open the "approve/activate" URL again, again "Invalid activation code" (should say: "already activated!")
additional test:
- from the elog config, user "test", set active to "no", save.
- open the "approve/activate" URL, get "Invalid activation code" (good, this time)
- check elog config, user "test" is still inactive (good)
So it looks like the "approve/activate" URL works correctly - only the first time it is accessed - but
returns wrong message "invalid activation code" instead of "success".
K.O.
|
|
69484
|
Thu Mar 3 16:49:40 2022 |
| Konstantin Olchanski | olchansk@triumf.ca | Question | Windows | 3.1.4-a04faf9f | Re: Vulnerability? |
The CVEs you refer to are very old and have been fixed a long time ago.
Please refer to:
https://www.tenable.com/security/research/tra-2019-53
This report states that all the reported problems are fixed as of ELOG 3.1.4-283534d or later.
Note that the elog git history does not refer to these CVEs because
they were fixed before the CVE number was assigned, per "Disclosure Timeline"
in the above document. The relevant commits are listed under "Additional References".
K.O. |
|
69487
|
Sun Mar 6 17:33:04 2022 |
| Konstantin Olchanski | olchansk@triumf.ca | Question | Windows | 3.1.4-a04faf9f | Re: Vulnerability? |
> > > The CVEs you refer to are very old and have been fixed a long time ago.
>
> Am I wrong that the windows executable version on the site is dated 2018? 3.1.4-2?
I confirm. Windows executables at https://elog.psi.ch/elog/download/windows/
and Debian packages at https://packages.debian.org/search?keywords=elog all
appear to be older than the cve fixes.
I trust Stefan is reading this thread and will do something about it. My vote would
be to remove the download link to the windows executables and ask Debian to remove
the elog package. I think they have a way for upstream developers (Stefan) to request
removal of unmaintained out-of-date insecure versions of their stuff. ROOT
was in the same situation years ago, the Debian package for ROOT was very old version,
also built incorrectly, and everybody complained to us that our stuff does
not work (midas, rootana, etc).
K.O. |
|
69498
|
Fri Mar 18 00:36:37 2022 |
 | Konstantin Olchanski | olchansk@triumf.ca | Bug report | Linux | ELOG V3.1.4-2e1 | http status 200 returned for "file not found" |
"file not found" should return http code 404. elogd returns code 200 together
with a page containing text "404 not found". This pollutes the browser cache
with wrong content (in this case, we are trying to load a css file, and the browser
is trying to use text "404 not found" as if it were a css. bad. file not found
should return http code 404. K.O.
in example below, response "HTTP/1.1 200 Document follows" should be "HTTP/1.1 404 ..."
to reproduce, through the https proxy:
daq00:~$ curl -v https://daq00.triumf.ca/elog-midas/Midas/zzz.css
* Trying 142.90.111.168:443...
...
> GET /elog-midas/Midas/zzz.css HTTP/1.1
...
< HTTP/1.1 200 Document follows
< Date: Thu, 17 Mar 2022 23:40:04 GMT
< Server: ELOG HTTP 3.1.4-2e1708b5
< Strict-Transport-Security: max-age=31536000; includeSubDomains
< Content-Type: text/html;charset=ISO-8859-1
< Vary: Accept-Encoding
< Transfer-Encoding: chunked
<
<!DOCTYPE html>
<html><head>
<meta name="ROBOTS" content="NOINDEX, NOFOLLOW">
<title>404 Not Found</title>
<link rel="stylesheet" type="text/css" href="elog.css">
<link rel="shortcut icon" href="favicon.ico" />
<link rel="icon" href="favicon.png" type="image/png" />
</head>
<body><h1>404 Not Found</h1>
The requested file <b>zzz.css</b> was not found on this server<p>
* Connection #0 to host daq00.triumf.ca left intact
daq00:~$
directly:
daq00:~$ curl -v http://localhost:9080/Midas/zzz.css
* Trying 127.0.0.1:9080...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 9080 (#0)
> GET /Midas/zzz.css HTTP/1.1
> Host: localhost:9080
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 Document follows
< Server: ELOG HTTP 3.1.4-2e1708b5
< Content-Type: text/html;charset=ISO-8859-1
< Connection: Close
<
<!DOCTYPE html>
<html><head>
<meta name="ROBOTS" content="NOINDEX, NOFOLLOW">
<title>404 Not Found</title>
<link rel="stylesheet" type="text/css" href="elog.css">
<link rel="shortcut icon" href="favicon.ico" />
<link rel="icon" href="favicon.png" type="image/png" />
</head>
<body><h1>404 Not Found</h1>
The requested file <b>zzz.css</b> was not found on this server<p>
* Closing connection 0
daq00:~$ |
|
69508
|
Mon Apr 18 21:01:23 2022 |
| Konstantin Olchanski | olchansk@triumf.ca | Question | Linux | not known | Re: recovery of elog from backup disk |
unfortunately instructions do not exist to cover every possible situation.
but in general, to migrate elog to a new machine, I would say do this:
- on new machine, install new elog from scratch
- copy the old elogs from "logbooks" on the backup disk to the new elog "logbooks"
- merge the config file by hand (this may require a few tries)
feel free to ask for more help with any of these steps here.
K.O. |
|
69513
|
Tue Apr 19 21:15:19 2022 |
| Konstantin Olchanski | olchansk@triumf.ca | Question | Windows | 3.1.4-a04faf9f | Re: Vulnerability? |
> it would be good if the current state was listed in https://elog.psi.ch/elogs/Vulnerabilities/
> It seems there's now updated builds for at least windows
I checked with Stefan and he plans to address both of those fairly soon.
> debian package still outdated?
We reached to the package maintainer (who is not us), if he cannot help,
we will request package removal through debian official channels. Then we have
to repeat same for the ubuntu package.
> A clear central source would be best ...
this already exists. git clone, make, run.
> p.s.: My hat is off to the sysadmin who checked carefully, I wanted to introduce ELOG in a windows-centric place and I can't swear I
would have checked this (official) download as well.
I usually check the date of stuff I install and go "hmm..." if it is not super fresh or very fresh.
K.O. |
|
69520
|
Fri Apr 22 21:15:37 2022 |
| Konstantin Olchanski | olchansk@triumf.ca | Question | Windows | 3.1.4-a04faf9f | Re: Vulnerability? |
> > debian package still outdated?
> We reached to the package maintainer
the good Roger Kalt requested removal of debian package elog
and it is now removed from debian-unstable. I am not sure
if it can be removed from debian-stable releases (debian-11, debian-10).
https://tracker.debian.org/pkg/elog
https://tracker.debian.org/news/1320035/removed-313-1-1-from-unstable/
K.O. |
|
69521
|
Sat Apr 23 18:05:57 2022 |
| Konstantin Olchanski | olchansk@triumf.ca | Question | Windows | 3.1.4-a04faf9f | Re: Vulnerability? |
> The CVEs you refer to are very old and have been fixed a long time ago.
>
> Please refer to:
> https://www.tenable.com/security/research/tra-2019-53
>
> This report states that all the reported problems are fixed as of ELOG 3.1.4-283534d or later.
>
> Note that the elog git history does not refer to these CVEs because
> they were fixed before the CVE number was assigned, per "Disclosure Timeline"
> in the above document. The relevant commits are listed under "Additional References".
>
> K.O.
I should better capture these "additional references" and the "disclosure timeline"
before they vanish from tenable.com:
https://www.tenable.com/security/research/tra-2019-53
Additional References
https://bitbucket.org/ritt/elog/commits/7367647d40d9b43d529d952d3a063d53606697cb
https://bitbucket.org/ritt/elog/commits/38c08aceda8e5ac4bfdcc040710b5792bd5fe4d3
https://bitbucket.org/ritt/elog/commits/32ba07e19241e0bcc68aaa640833424fb3001956
https://bitbucket.org/ritt/elog/commits/15787c1edec1bbe1034b5327a9d6efa710db480b
https://bitbucket.org/ritt/elog/commits/283534d97d5a181b09960ae1f0c53dbbe42d8a90
Disclosure Timeline
12/3/2019 - Notice sent to stefan.ritt - AT - psi.ch. 90 day is March 3, 2020
12/4/2019 - Dr. Ritt acknowledges the report.
12/9/2019 - Dr. Ritt stages fixes in bitbucket.
12/9/2019 - Tenable provides feedback.
12/10/2019 - Dr. Ritt acknowledges.
12/11/2019 - Tenable reserves CVE.
12/11/2019 - Tenable notes the various ELOG instances maintained by Paul Scherrer Institute are patched.
12/11/2019 - Tenable informs Dr. Ritt and Mr. Roger Kalt (Debian/Ubuntu package manager) of intent to publish CVE tomorrow (Dec.
12).
K.O. |