Hi Stefan,
  

> Hi Stefano,
> 
> well, why in heaven's name do you run 200+ chars file names?

This is a very good question, and I asked the same to my user: the use case is typically that the attachment names are generated programmatcally, and many steps of the script add a string to it, plus sometime the original filename has hiragana or even kanji character.

So, long story short, it has happened in our production environment

The file I'm using was indeed generated from /dev/random, but that was the earies way fo rme to create such long filename.

Backtrace with lines is as follow.

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) where
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff7cf4859 in __GI_abort () at abort.c:79
#2  0x00007ffff7d5f29e in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7e8908f "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x00007ffff7e01aea in __GI___fortify_fail (msg=msg@entry=0x7ffff7e89025 "buffer overflow detected") at fortify_fail.c:26
#4  0x00007ffff7e00386 in __GI___chk_fail () at chk_fail.c:28
#5  0x00007ffff7d5707f in _IO_str_chk_overflow (fp=<optimized out>, c=<optimized out>) at iovsprintf.c:35
#6  0x00007ffff7d64054 in __GI__IO_default_xsputn (n=<optimized out>, data=<optimized out>, f=<optimized out>) at libioP.h:948
#7  __GI__IO_default_xsputn (f=0x7ffffff36c70, data=<optimized out>, n=241) at genops.c:370
#8  0x00007ffff7d4912c in __vfprintf_internal (s=s@entry=0x7ffffff36c70, format=format@entry=0x555555622e74 "../%s/%s/%s", ap=ap@entry=0x7ffffff36db0, mode_flags=mode_flags@entry=6) at ../libio/libioP.h:948
#9  0x00007ffff7d57129 in __vsprintf_internal (
    string=0x7ffffff370f0 "../DAQ/220329_090332/IjU4CK54jRBuQhOdUANqC6X8i8x1yoGGKozhtuM2M0Cc8MnauDwSzAs0BiVwAIzyC4TJqmDArrIA9Exja36xXqc6PSUjOE5hkiW1YeG1R9FM64tmdq52vvo1NsqLOk6I02RBlgnQB7hoUQa1fwb8ZdoRo3BJ9WJGq2sErewo8BL9dAZhZF9"..., maxlen=<optimized out>, format=0x555555622e74 "../%s/%s/%s", 
args=args@entry=0x7ffffff36db0, mode_flags=6) at iovsprintf.c:95
#10 0x00007ffff7dffe7b in ___sprintf_chk (s=<optimized out>, flag=<optimized out>, slen=<optimized out>, format=<optimized out>) at sprintf_chk.c:40
#11 0x00005555555a939d in sprintf (__fmt=0x555555622e74 "../%s/%s/%s", __s=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/stdio2.h:36
#12 display_line (lbs=0x55555664b818, message_id=9, number=<optimized out>, mode=0x7ffffffd2b80 "Summary", expand=1, level=0, printable=0, n_line=3, show_attachments=0, show_att_column=1, 
    date=0x7ffffffd2a40 "Tue, 29 Mar 2022 09:03:35 +0000", in_reply_to=0x7ffffffd2a90 "", reply_to=0x7ffffffd3160 "", n_attr_disp=7, disp_attr=0x7ffffff86760, disp_attr_link=0x7ffffff386a0, attrib=0x7ffffff3d380, 
    n_attr=5, text=0x5555567f26f8 "", show_text=1, attachment=0x7ffffff3a180, encoding=0x7ffffffd2ae0 "plain", select=0, n_display=0x7ffffff38438, locked_by=0x7ffffffd2d60 "", highlight=0, re_buf=0x7ffffff38840, 
    highlight_mid=0, absolute_link=0, draft=0x7ffffffd2f60 "") at src/elogd.c:18214
#13 0x00005555555ddc8a in show_elog_list (lbs=<optimized out>, past_n=<optimized out>, last_n=<optimized out>, page_n=<optimized out>, default_page=<optimized out>, info=<optimized out>) at src/elogd.c:21741
#14 0x00005555556010cf in interprete (lbook=<optimized out>, path=<optimized out>) at src/elogd.c:28362
#15 0x0000555555601a33 in decode_get (logbook=0x7fffffffbda0 "DAQ", string=<optimized out>) at src/elogd.c:28401
#16 0x000055555560461f in process_http_request (request=<optimized out>, i_conn=<optimized out>) at src/elogd.c:29209
#17 0x0000555555607745 in server_loop () at src/elogd.c:30233
#18 0x000055555555a92c in main (argc=<optimized out>, argv=<optimized out>) at src/elogd.c:31258


I'm not using the latest git version, but elog-3.1.4-3 from tar-ball, as I'm not able to compile elog from git
Is there any special thing I have to do?

In file included from src/auth.cxx:30:
src/elogd.h:282:40: note:   initializing argument 2 of ‘int get_user_line(LOGBOOK*, char*, char*, char*, char*, BOOL*, time_t*, int*)’
  282 | int get_user_line(LOGBOOK * lbs, char *user, char *password, char *full_name, char *email,
      |                                  ~~~~~~^~~~
make: *** [Makefile:140: auth.o] Error 1

thanks for your help.

Stefano


I see that they are generated probably automatically, but I guess you will run in all kinds of other problems in doing that.
> 
> I had a check with elogd. I found one buffer overflow once you delete an attachment with a long file name. I fixed that and committed the change.
> 
> Concerning your crash, I was not able to reproduce it. Used a 255 char long filename, and could NOT crash elogd. Maybe you have an oder version or some special config options which
> trigger that crash. Try with the newest git version and a minimal elogd.cfg configuration. Please also add line numbers during compilation (-g -o0 flags) so that I can better analyze
> your backtrace. Best would be if I could reproduce your error.
> 
> Best,
> Stefan
> 
> 
> 
> > Hi,
> >   I'm running 
> > elogd 3.1.4 built Jan 27 2021, 09:56:34 revision 395e101a
> > on an ubuntu server.
> > 
> > I have a crash when very long filename (200 chars) are attached to an logbook entry.
> > 
> > The uploading of the attachment works almost fine: the filename is truncated and the convert to thumbnail is not working (as a consequence, maybe) but the file is actually uploaded and can be 
> > downloaded correctly from the entry itself.
> > 
> > However, if I try to access the logbook list which contains that entry, I have a crash:
> > 
> > *** buffer overflow detected ***: terminated
> > Aborted (core dumped)
> > 
> > [backtrace is attached below]
> > 
> > The only way I found to solve this is to edit manually the log entry and delete the attachment from it.
> > 
> > Any suggestion how to solve this?
> > 
> > Thanks
> >   Stefano
> > 
> > 
> > *** buffer overflow detected ***: terminated
> > 
> > Program received signal SIGABRT, Aborted.
> > __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> > 50	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> > (gdb) bp
> > Undefined command: "bp".  Try "help".
> > (gdb) backtrace 
> > #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> > #1  0x00007ffff7cf4859 in __GI_abort () at abort.c:79
> > #2  0x00007ffff7d5f29e in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7e8908f "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:155
> > #3  0x00007ffff7e01aea in __GI___fortify_fail (msg=msg@entry=0x7ffff7e89025 "buffer overflow detected") at fortify_fail.c:26
> > #4  0x00007ffff7e00386 in __GI___chk_fail () at chk_fail.c:28
> > #5  0x00007ffff7d5707f in _IO_str_chk_overflow (fp=<optimized out>, c=<optimized out>) at iovsprintf.c:35
> > #6  0x00007ffff7d64054 in __GI__IO_default_xsputn (n=<optimized out>, data=<optimized out>, f=<optimized out>) at libioP.h:948
> > #7  __GI__IO_default_xsputn (f=0x7ffffff36ca0, data=<optimized out>, n=241) at genops.c:370
> > #8  0x00007ffff7d4912c in __vfprintf_internal (s=s@entry=0x7ffffff36ca0, format=format@entry=0x555555622e74 "../%s/%s/%s", ap=ap@entry=0x7ffffff36de0, mode_flags=mode_flags@entry=6)
> >     at ../libio/libioP.h:948
> > #9  0x00007ffff7d57129 in __vsprintf_internal (
> >     string=0x7ffffff37120 
> > "../DAQ/220325_090630/j5K1OSy8XN9FRPriaBGOmMg3bih07CQKo68Sw6dskclxdOqKaTOsf2bX8UugSWn0s8zaAHe6VWiPcQVnmD8PM1tbQoVMr08dBrXKU2X2tBR4pJ3hlfxbKjspmcbiDTMy32eHIp6lFAVA9lppShmpiut4g4CtgDK3F2bOPzgzXEjPw
> > W0SJWG"..., maxlen=<optimized out>, format=0x555555622e74 "../%s/%s/%s", args=args@entry=0x7ffffff36de0, mode_flags=6) at iovsprintf.c:95
> > #10 0x00007ffff7dffe7b in ___sprintf_chk (s=<optimized out>, flag=<optimized out>, slen=<optimized out>, format=<optimized out>) at sprintf_chk.c:40
> > #11 0x00005555555a939d in display_line ()
> > #12 0x00005555555ddc8a in show_elog_list ()
> > #13 0x00005555556010cf in interprete ()
> > #14 0x0000555555601a33 in decode_get ()
> > #15 0x000055555560461f in process_http_request ()
> > #16 0x0000555555607745 in server_loop ()
> > #17 0x000055555555a92c in main ()

> > 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).
> 
> Yeah, I have to recompile the Windows version. Unfortunately my old Windows PC is gone, I
> switched now completely to MacOSX and Linux. Probably have to borrow something from somewhere.
> If anybody can compile the Windows version with the current source code I would be happy.

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, and the debian package still outdated?

Personally, I don't think removing download links and pulling packages should be more than a temporary measure.
Treating people fairly IMHO means they should be able to reach a safe version by the same means that brought and left them exposed.

A clear central source would be best, one that has 

- package autobuilds
- source
- cve list

If I understand correctly, currently only the source is up to date?


(I found py_elog on Github, so it could be an easy option to mirror ELOG there and let some free service handle the autobuilds.
I don't know how well one can flag vulnerabilities there, but likely it's possible, and ideally more people would help there.)


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.

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.

Sure. Just figure out the URL from your browser and then use it in wget, e.g.

wget https://elog.psi.ch/elogs/Forum/220309_175728/elog-3.1.4-1ebfd06c-win64.zip

to download one attachement from this forum.

Stefan

> I've built the last C version of elog in git, revision 1ebfd06c using mingw-64 ; the resulting binaries work for me on Windows 2019.
> Attached is a zip file with the binaries.
> I was not able to create a new installer, these are just the executables

I tried to just exchange the attached binaries in my installation but this didn't worked.
elogd was not able to start.

Regards,

daniel

> > I've built the last C version of elog in git, revision 1ebfd06c using mingw-64 ; the resulting binaries work for me on Windows 2019.
> > Attached is a zip file with the binaries.
> > I was not able to create a new installer, these are just the executables
> 
> I tried to just exchange the attached binaries in my installation but this didn't worked.
> elogd was not able to start.

hmmm strange - did you get an error message or did the binary simply not start?  I've only tested this on a single Windows machine....

> > > I've built the last C version of elog in git, revision 1ebfd06c using mingw-64 ; the resulting binaries work for me on Windows 2019.
> > > Attached is a zip file with the binaries.
> > > I was not able to create a new installer, these are just the executables
> > 
> > I tried to just exchange the attached binaries in my installation but this didn't worked.
> > elogd was not able to start.
> 
> hmmm strange - did you get an error message or did the binary simply not start?  I've only tested this on a single Windows machine....

Error message is:

Error 1053: The service did not respond to the start or control request in a timely fashion.

I have to admit that I'm doing all this on a Server 2012 machine.