sogo issue

M

Max212

I've installed sogo and required dependencies from packages.
If I try to login with valid username and incorrect password, service behaves as expected and notifies incorrect login.
When I try to login with correct credentials, service responds with Unhandled error response.

Logs show that sogod process/service restarts at time of correct credential entry.
Should I contact port maintainer or original authors of the application?


Excerpt from sogod log:
Code: 
Sep 27 14:01:08 sogod [1019]: |SOGo| starting method 'POST' on uri '/SOGo/connect'
2022-09-27 14:01:08.287 sogod[1019:100274] PostgreSQL72 connection established: <0x0x803e1af68[PGConnection]:  connection=0x0x804aaf000>
2022-09-27 14:01:08.287 sogod[1019:100274] PostgreSQL72 channel 0x0x804874168 opened (connection=<0x0x803e1af68[PGConnection]:  connection=0x0x804aaf000>, count=1)
2022-09-27 14:01:08.288 sogod[1019:100274] PG0x0x804874168 SQL: SELECT c_password FROM sogo_users WHERE c_uid = 'admin'
Sep 27 14:01:08 sogod [1017]: <0x0x8048cf148[WOWatchDogChild]> child 1019 exited
Sep 27 14:01:08 sogod [1017]: <0x0x8048cf148[WOWatchDogChild]>  (terminated due to signal 6)
Sep 27 14:01:08 sogod [1017]: <0x0x803e89738[WOWatchDog]> child spawned with pid 1259
2022-09-27 14:01:08.635 sogod[1259:100274] PostgreSQL72 connection established: <0x0x8046f3288[PGConnection]:  connection=0x0x804aae000>
2022-09-27 14:01:08.636 sogod[1259:100274] PostgreSQL72 channel 0x0x804871dc8 opened (connection=<0x0x8046f3288[PGConnection]:  connection=0x0x804aae000>, count=1)

Excerpt from messages log:
Code: 
Sep 27 16:01:08 sogotest sogod[1019]: stack overflow detected; terminated
Sep 27 16:01:08 sogotest kernel: pid 1019 (sogod), jid 0, uid 846: exited on signal 6
 
I experience the same issue. Please share if you find a solution.
Code: 
# freebsd-version
13.1-RELEASE-p2
# pkg version -v | egrep "sogo|postgre"
postgresql13-client-13.8           =   up-to-date with index
postgresql13-server-13.8           =   up-to-date with index
sogo-activesync-5.7.0_2            =   up-to-date with index
 
I've tested sogo 5.5.1 on OpenBSD 7.1 and it worked fine.
After upgrading to OpenBSD 7.2 and sogo to 5.7.1 similar problem occurred.
 
Program crashed (aborted) due to stack overflow. Either that sql handling password got crazy or you hit a stack limit. I personally never heard about "sogo" before. But if you have a crash dump we could narrow that down.
Under the user you start sogo, what does this command say: ulimit -s.
 
_martin said:
Program crashed (aborted) due to stack overflow. Either that sql handling password got crazy or you hit a stack limit. I personally never heard about "sogo" before. But if you have a crash dump we could narrow that down.
Under the user you start sogo, what does this command say: ulimit -s.
Click to expand...

It runs under sogod user and it has no home folder and no login
 
Max212 said:
Sogo does run. I've executed the command on last paragraph, still the same issue.
Click to expand...

On OpenBSD it was the issue with nginx buffers. This was the error in logs:
Code: 
nginx upstream sent too big header while reading response header from upstream

I've just increased the values of these parameters and now is working fine on OpenBSD.
Code: 
        proxy_buffer_size 256k;
        proxy_buffers 4 512k;
        proxy_busy_buffers_size 512k;
        proxy_temp_file_write_size 512k;

I'll check on FreeBSD if it will help.
 
Do you see any core files being generated? It would be hard to believe that one sql command would exhaust the memory limit php is being set to though you could probably fiddle around with that too.

But the error "stack overflow detected" suggest a problem with the overflow in the program (such as buffer overflow) as this message is coming from libc. That means that's a bug in the sogo itself then.
 
_martin said:
Do you see any core files being generated? It would be hard to believe that one sql command would exhaust the memory limit php is being set to though you could probably fiddle around with that too.

But the error "stack overflow detected" suggest a problem with the overflow in the program (such as buffer overflow) as this message is coming from libc. That means that's a bug in the sogo itself then.
Click to expand...

To my knowledge, sogo is written in Objective-C. Based on the error, there could be some strange bug in it.
 
You can still trigger BoF bugs in objective-c.
But this (catching overflow) is a security feature of a compiler, meaning the code was built with -fstack-protector-all or alike feature that does put canaries on stack and libc can hook them (that's why you can see "stack overflow detected" in the syslog). Without that if it was an exploit you'd see nothing, with basic overflow you'd see SIGSEGV most likely.

That error is proof that you caught a bug. Raising buffers may hide that bug though.

The best way is to contact the developer. You could attach gdb to a running process and wait for the crash. Backtrace would tell you where that issue occurred.
 
_martin said:
You can still trigger BoF bugs in objective-c.
But this (catching overflow) is a security feature of a compiler, meaning the code was built with -fstack-protector-all or alike feature that does put canaries on stack and libc can hook them (that's why you can see "stack overflow detected" in the syslog). Without that if it was an exploit you'd see nothing, with basic overflow you'd see SIGSEGV most likely.
Click to expand...

In general I understand what are you talking about, but I have no idea how to execute any of it.
 
When you said it's objective-c my enthusiasm to debug it lowered significantly. :)

But you could do this: start the sogo and find out its pid. Use gdb -p <pid> to attach to it. Enter c as a command in gdb (followed by enter) to let the process continue its execution. Do whatever you do to trigger the bug. Now once you hit the issue gdb should show you a stack trace and enter its prompt again. You can even execute bt command to show backtrace of the problem. That's the first step in debugging the issue.
 
_martin said:
When you said it's objective-c my enthusiasm to debug it lowered significantly. :)

But you could do this: start the sogo and find out its pid. Use gdb -p <pid> to attach to it. Enter c as a command in gdb (followed by enter) to let the process continue its execution. Do whatever you do to trigger the bug. Now once you hit the issue gdb should show you a stack trace and enter its prompt again. You can even execute bt command to show backtrace of the problem. That's the first step in debugging the issue.
Click to expand...

I'm absolutely no expert in interpreting the output in gdb, so any help here would be highly appreciated :)

# gdb -p 69725 ... Attaching to process 69725 ... Reading symbols from /usr/local/GNUstep/Local/Library/SOGo/PreferencesUI.SOGo/PreferencesUI... Reading symbols from /usr/local/GNUstep/Local/Library/GDLAdaptors-4.9/PostgreSQL.gdladaptor/PostgreSQL... Reading symbols from /usr/local/lib/libpq.so.5... Reading symbols from /libexec/ld-elf.so.1... (No debugging symbols found in /libexec/ld-elf.so.1) [Switching to LWP 100659 of process 69725] 0x21bbf26f in _poll () from /lib/libc.so.7 (gdb) c Continuing. Program received signal SIGABRT, Aborted. Sent by kill() from pid 69725 and user 846. 0x21bbdb0f in kill () from /lib/libc.so.7 (gdb) bt #0 0x21bbdb0f in kill () from /lib/libc.so.7 #1 0x21bbf58e in ?? () from /lib/libc.so.7 #2 0x21bbf4db in __stack_chk_fail () from /lib/libc.so.7 #3 0x210d776f in +[NSData(SOGoCryptoExtension) decodeDataFromHexString:] () from /usr/local/GNUstep/Local/Library/Libraries/sogo/libSOGo.so.5 #4 0x210d6e41 in -[NSString(SOGoCryptoExtension) isEqualToCrypted:withDefaultScheme:keyPath:] () from /usr/local/GNUstep/Local/Library/Libraries/sogo/libSOGo.so.5 #5 0x210cdc98 in -[SQLSource _isPassword:equalTo:] () from /usr/local/GNUstep/Local/Library/Libraries/sogo/libSOGo.so.5 #6 0x210ce0e9 in -[SQLSource checkLogin:password:perr:expire:grace:] () from /usr/local/GNUstep/Local/Library/Libraries/sogo/libSOGo.so.5 #7 0x210c3da6 in -[SOGoUserManager _sourceCheckLogin:andPassword:domain:perr:expire:grace:] () from /usr/local/GNUstep/Local/Library/Libraries/sogo/libSOGo.so.5 #8 0x210c42e8 in -[SOGoUserManager checkLogin:password:domain:perr:expire:grace:useCache:] () from /usr/local/GNUstep/Local/Library/Libraries/sogo/libSOGo.so.5 #9 0x210dc21e in -[SOGoWebAuthenticator checkLogin:password:domain:perr:expire:grace:useCache:] () from /usr/local/GNUstep/Local/Library/Libraries/sogo/libSOGo.so.5 #10 0x23e169a5 in -[SOGoRootPage connectAction] () from /usr/local/GNUstep/Local/Library/SOGo/MainUI.SOGo/MainUI #11 0x2191e9db in -[NSObject performSelector:] () from /usr/local/GNUstep/System/Library/Libraries/libgnustep-base.so.1.27 #12 0x212c8c39 in -[WOComponent(DirectActionExtensions) performActionNamed:] (self=0x232f7a94, _cmd=0x23df21d0 <.objc_selector_performActionNamed:_>, _actionName=<optimized out>) at WOPageRequestHandler.m:245 #13 0x23de8691 in -[UIxComponent performActionNamed:] () from /usr/local/GNUstep/Local/Library/Libraries/sogo/libSOGoUI.so.5.7 #14 0x2131a09f in -[SoActionInvocation callOnObject:withPositionalParametersWhenNotNil:inContext:] (self=0x238e6324, _cmd=0x2139fddc <.objc_selector_callOnObject:withPositionalParametersWhenNotNil:inContext:_200:481216>, _client=0x232f41b4, _positionalArgs=0x0, _ctx=0x24175204) at SoActionInvocation.m:300 #15 0x2131a137 in -[SoActionInvocation callOnObject:inContext:] (self=0x238e6324, _cmd=0x2139fc3c <.objc_selector_callOnObject:inContext:_160:4812>, _client=0x232f41b4, _ctx=0x24175204) at SoActionInvocation.m:316 #16 0x21316a7f in -[SoObjectMethodDispatcher dispatchInContext:] (self=0x23784554, _cmd=0x2139fc64 <.objc_selector_dispatchInContext:_120:48>, _ctx=0x24175204) at SoObjectMethodDispatcher.m:191 #17 0x213180f8 in -[SoObjectRequestHandler handleRequest:inContext:session:application:] (self=0x2361d424, _cmd=0x2139dc9c <.objc_selector_handleRequest:inContext:session:application:_240:48121620>, _rq=0x23603184, _ctx=0x24175204, _sn=0x0, app=0x232f41b4) at SoObjectRequestHandler.m:584 #18 0x212c9d0d in -[WORequestHandler handleRequest:] (self=0x2361d424, _cmd=0x2139ccec <.objc_selector_handleRequest:_120:48>, _request=0x23603184) at WORequestHandler.m:237 #19 0x212a1d1f in -[WOCoreApplication dispatchRequest:usingHandler:] (self=0x232f41b4, _cmd=0x2139cd04 <.objc_selector_dispatchRequest:usingHandler:_160:4812>, _request=0x23603184, handler=0x2361d424) at WOCoreApplication.m:712 #20 0x212a1ef1 in -[WOCoreApplication dispatchRequest:] (self=0x232f41b4, _cmd=0x100db7c <.objc_selector_dispatchRequest:_>, _request=0x23603184) at WOCoreApplication.m:752 #21 0x0100919a in -[SOGo dispatchRequest:] () #22 0x2130d12a in -[WOHttpTransaction _run] (self=0x2386c6e4, _cmd=0x2139f6b4 <.objc_selector__run_C80:4>) at WOHttpTransaction.m:566 #23 0x2130d383 in -[WOHttpTransaction run] (self=0x2386c6e4, _cmd=0x2139f554 <.objc_selector_run_C80:4>) at WOHttpTransaction.m:619 #24 0x2130a886 in -[WOHttpAdaptor runConnection:] (self=0x2377cec4, _cmd=0x2139f564 <.objc_selector_runConnection:_C120:48>, _socket=0x2377cf44) at WOHttpAdaptor.m:373 #25 0x2130aa2a in -[WOHttpAdaptor _handleAcceptedConnection:] (self=0x2377cec4, _cmd=0x2139f56c <.objc_selector__handleAcceptedConnection:_v120:48>, _connection=0x2377cf44) at WOHttpAdaptor.m:407 #26 0x2130acc9 in -[WOHttpAdaptor _handleConnection:] (self=0x2377cec4, _cmd=0x2139f5a4 <.objc_selector__handleConnection:_v120:48>, connection=0x2377cf44) at WOHttpAdaptor.m:466 --Type <RET> for more, q to quit, c to continue without paging-- #27 0x2130aee1 in -[WOHttpAdaptor acceptControlMessage:] (self=0x2377cec4, _cmd=0x2139f524 <.objc_selector_acceptControlMessage:_>, aNotification=0x23886724) at WOHttpAdaptor.m:505 #28 0x2191ea9e in -[NSObject performSelector:withObject:] () from /usr/local/GNUstep/System/Library/Libraries/libgnustep-base.so.1.27 #29 0x21913481 in -[NSNotificationCenter _postAndRelease:] () from /usr/local/GNUstep/System/Library/Libraries/libgnustep-base.so.1.27 #30 0x219139f0 in -[NSNotificationCenter postNotificationName:object:userInfo:] () from /usr/local/GNUstep/System/Library/Libraries/libgnustep-base.so.1.27 #31 0x21913947 in -[NSNotificationCenter postNotificationName:object:] () from /usr/local/GNUstep/System/Library/Libraries/libgnustep-base.so.1.27 #32 0x214ec5b1 in -[NSObject(FileObjectWatcher) receivedEvent:type:extra:forMode:] (self=0x236ee7c4, _cmd=0x21a5ab88 <.objc_selector_receivedEvent:type:extra:forMode:_v240:4^v8i12^v1620>, _fdData=0x8, _type=ET_RDESC, _extra=0x8, _mode=0x21a4ee88 <.objc_str_NSDefaultRunLoopMode>) at NSRunLoop+FileObjects.m:57 #33 0x219f89a1 in -[GSRunLoopCtxt pollUntil:within:] () from /usr/local/GNUstep/System/Library/Libraries/libgnustep-base.so.1.27 #34 0x21951dbe in -[NSRunLoop acceptInputForMode:beforeDate:] () from /usr/local/GNUstep/System/Library/Libraries/libgnustep-base.so.1.27 #35 0x21952192 in -[NSRunLoop runMode:beforeDate:] () from /usr/local/GNUstep/System/Library/Libraries/libgnustep-base.so.1.27 #36 0x212a1823 in -[WOCoreApplication run] (self=0x232f41b4, _cmd=0x100da2c <objc_selector_run_>) at WOCoreApplication.m:584 #37 0x010088ea in -[SOGo run] () #38 0x212cfcf1 in -[WOWatchDog _runChildWithControlSocket:] (self=0x236ee784, _cmd=0x2139ea1c <.objc_selector__runChildWithControlSocket:_v120:48>, controlSocket=0x236ee7c4) at WOWatchDogApplicationMain.m:523 #39 0x212d00a1 in -[WOWatchDog _spawnChild:] (self=0x236ee784, _cmd=0x2139ea34 <.objc_selector__spawnChild:_C120:48>, child=0x2381e5f4) at WOWatchDogApplicationMain.m:600 #40 0x212d0523 in -[WOWatchDog _ensureChildren] (self=0x236ee784, _cmd=0x2139eab4 <.objc_selector__ensureChildren_C80:4>) at WOWatchDogApplicationMain.m:690 #41 0x212d1148 in -[WOWatchDog run:argc:argv:] (self=0x236ee784, _cmd=0x2139eadc <objc_selector_run:argc:argv:_i200:48i12r^*16>, newAppName=0x100def4 <.objc_str_SOGo>, newArgC=1, newArgV=0xffbfe99c) at WOWatchDogApplicationMain.m:942 #42 0x212d1549 in WOWatchDogApplicationMain (appName=0x100def4 <.objc_str_SOGo>, argc=1, argv=0xffbfe99c) at WOWatchDogApplicationMain.m:1051 #43 0x01007d95 in main () (gdb)
 
freebox Thanks. So issue is in frame 3:
Code: 
#3  0x210d776f in +[NSData(SOGoCryptoExtension) decodeDataFromHexString:] () from /usr/local/GNUstep/Local/Library/Libraries/sogo/libSOGo.so.5
In gdb, once it fails, can you do this:
Code: 
f 3
x/12i $pc
Can you share the cksum of /usr/local/GNUstep/Local/Library/Libraries/sogo/libSOGo.so.5 ? If you can run this on something not important, meaning you don't use real password you'd use, could you upload the core dump? I could look around the crash and maybe tell you more.
For comparison the lib I got from ports right now is this (I'm using the path to actual library, above path is link that eventually resolves to this):
Code: 
# cksum /usr/local/GNUstep/Local/Library/Frameworks/SOGo.framework/Versions/5/sogo/libSOGo.so.5.7.0
3057549314 1339200 /usr/local/GNUstep/Local/Library/Frameworks/SOGo.framework/Versions/5/sogo/libSOGo.so.5.7.0
#

Frankly I've never seen a line in objective C but failure seems to be in this one: decodeDataFromHexString() . If I read the code correctly there's only one write and that is dstBuffer[] which is a local variable (stack). So very likely issue is here.
 
Code: 
(gdb) f 3
#3  0x210d776f in +[NSData(SOGoCryptoExtension) decodeDataFromHexString:] ()
   from /usr/local/GNUstep/Local/Library/Libraries/sogo/libSOGo.so.5
(gdb) x/12i $pc
=> 0x210d776f:  nop
   0x210d7770 <_c_NSData_SOGoCryptoExtension_generateSaltForLength_>:   push   %ebp
   0x210d7771 <_c_NSData_SOGoCryptoExtension_generateSaltForLength_+1>: mov    %esp,%ebp
   0x210d7773 <_c_NSData_SOGoCryptoExtension_generateSaltForLength_+3>: push   %ebx
   0x210d7774 <_c_NSData_SOGoCryptoExtension_generateSaltForLength_+4>:
    call   0x210d7779 <_c_NSData_SOGoCryptoExtension_generateSaltForLength_+9>
   0x210d7779 <_c_NSData_SOGoCryptoExtension_generateSaltForLength_+9>: pop    %ebx
   0x210d777a <_c_NSData_SOGoCryptoExtension_generateSaltForLength_+10>:        add    $0x24597,%ebx
   0x210d7780 <_c_NSData_SOGoCryptoExtension_generateSaltForLength_+16>:        mov    -0x16ff4(%ebx),%eax
   0x210d7786 <_c_NSData_SOGoCryptoExtension_generateSaltForLength_+22>:        lea    -0x1074(%ebx),%ecx
   0x210d778c <_c_NSData_SOGoCryptoExtension_generateSaltForLength_+28>:        push   $0x0
   0x210d778e <_c_NSData_SOGoCryptoExtension_generateSaltForLength_+30>:        push   0x10(%ebp)
   0x210d7791 <_c_NSData_SOGoCryptoExtension_generateSaltForLength_+33>:        push   %ecx
(gdb)

Code: 
# cksum /usr/local/GNUstep/Local/Library/Libraries/sogo/libSOGo.so.5
876716886 1068600 /usr/local/GNUstep/Local/Library/Libraries/sogo/libSOGo.so.5

Actually I don't have a core dump, since there are two sogod processes runninng, and to me it looks like only the child process dies, and the main process starts a new child. I don't know how to force and get a core dump from the child..
 
Yeah, that disassembly doesn't help much, I realized that as I posted it. As we know stack_chk_fail() was called we know we are somewhere in the end of the function.
To generate a core file within gdb you can use generate-core-file command.

I installed sogo from ports:
Code: 
# pkg info sogo\*
sogo-activesync-5.7.0_2
# pkg list sogo-activesync-5.7.0_2|grep libSOGo.so.5|xargs cksum
3864681566 1339200 /usr/local/GNUstep/Local/Library/Frameworks/SOGo.framework/Versions/5/sogo/libSOGo.so.5
3864681566 1339200 /usr/local/GNUstep/Local/Library/Frameworks/SOGo.framework/Versions/5/sogo/libSOGo.so.5.7.0
3864681566 1339200 /usr/local/GNUstep/Local/Library/Libraries/sogo/libSOGo.so.5
3864681566 1339200 /usr/local/GNUstep/Local/Library/Libraries/sogo/libSOGo.so.5.7.0
Yet your library has different checksum. Did you install it from binary packages?

Would you share very quick howto configure your setup? I'd try it on my VM to see if I can reproduce the crash. I googled some howtos but all required sope4.9-gdl1-mysql package (for MySQL backend) but that is not in ports/packages.
 
I installed from binary packages, and use PostgreSQL as backend:
Code: 
# pkg list sogo-activesync-5.7.0_2 | grep libSOGo.so.5 | xargs cksum
427534641 1068600 /usr/local/GNUstep/Local/Library/Frameworks/SOGo.framework/Versions/5/sogo/libSOGo.so.5
427534641 1068600 /usr/local/GNUstep/Local/Library/Frameworks/SOGo.framework/Versions/5/sogo/libSOGo.so.5.7.0
427534641 1068600 /usr/local/GNUstep/Local/Library/Libraries/sogo/libSOGo.so.5
427534641 1068600 /usr/local/GNUstep/Local/Library/Libraries/sogo/libSOGo.so.5.7.0
# pkg info sope\*
sope-5.7.0
# pkg info postgres\*
postgresql13-client-13.8
postgresql13-server-13.8

I have also tried installing sogo from ports and also having the same issue.

Specific settings in /usr/local/etc/sogo/sogo.conf are:
Code: 
{
SOGoProfileURL = "postgresql://sogo:password@127.0.0.1:5432/sogo/sogo_user_profile";
OCSFolderInfoURL = "postgresql://sogo:password@127.0.0.1:5432/sogo/sogo_folder_info";
OCSSessionsFolderURL = "postgresql://sogo:password@127.0.0.1:5432/sogo/sogo_sessions_folder";
SOGoMailDomain = example.com;
SOGoUserSources =
  (
    {
      type = sql;
      id = directory;
      viewURL = "postgresql://sogo:password@127.0.0.1:5432/sogo/sogo_view";
      canAuthenticate = YES;
      isAddressBook = YES;
      userPasswordAlgorithm = md5;
    }
  );
SOGoTimeZone = Europe/Copenhagen;
SxVMemLimit = 300;
SOGoMemcachedHost = 127.0.0.1;
SOGoDebugRequests = YES;
SoDebugBaseURL = YES;
ImapDebugEnabled = YES;
PGDebugEnabled = YES;
SOGoUIxDebugEnabled = YES;
WODontZipResponse = YES;
}

For apache in /usr/local/etc/apache24/Includes/SOGo-Apache.conf:
Code: 
Alias /SOGo.woa/WebServerResources/ \
      /usr/local/GNUstep/Local/Library/SOGo/WebServerResources/
Alias /SOGo/WebServerResources/ \
      /usr/local/GNUstep/Local/Library/SOGo/WebServerResources/
<Directory /usr/local/GNUstep/Local/Library/SOGo/>
    AllowOverride None
    <IfVersion < 2.4>
        Order deny,allow
        Allow from all
    </IfVersion>
    <IfVersion >= 2.4>
        Require all granted
    </IfVersion>
    <IfModule expires_module>
      ExpiresActive On
      ExpiresDefault "access plus 1 year"
    </IfModule>
</Directory>
Header always set Referrer-Policy "same-origin"
<Location /SOGo>
  Header set Cache-Control "max-age=0, no-cache, no-store"
</Location>
ProxyRequests Off
ProxyPreserveHost On
SetEnv proxy-nokeepalive 1
SetEnv proxy-initial-not-pooled 1
SetEnv force-proxy-request-1.0 1
ProxyPass /Microsoft-Server-ActiveSync \
 http://127.0.0.1:20000/SOGo/Microsoft-Server-ActiveSync \
 retry=0 connectiontimeout=5 timeout=360
ProxyPass /SOGo http://127.0.0.1:20000/SOGo retry=0 nocanon
<Proxy http://127.0.0.1:20000/SOGo>
  <IfModule headers_module>
    RequestHeader set "x-webobjects-server-port" "443"
    SetEnvIf Host (.*) HTTP_HOST=$1
    RequestHeader set "x-webobjects-server-name" "example.com"
    RequestHeader set "x-webobjects-server-url" "https://example.com"
    RequestHeader set "x-webobjects-remote-user" "%{REMOTE_USER}e" env=REMOTE_USER
    RequestHeader set "x-webobjects-server-protocol" "HTTP/1.0"
  </IfModule>
  AddDefaultCharset UTF-8
  Order allow,deny
  Allow from all
</Proxy>

edit: curly brackets {} added at top and end in sogo.conf
 
I'm a bit confused why your library /usr/local/GNUstep/Local/Library/Libraries/sogo/libSOGo.so.5 has now different checksum from one you posted before. Did you show the cksum of the custom built package above?

Do I need to create specific db in pgsql ? Right now I've installed
Code: 
# pkg info sope\* sogo\* postg\*
sope-5.7.0
sogo-activesync-5.7.0_2
postgresql13-client-13.8
postgresql13-server-13.8
Using your sogo config 1:1 gives me an error
Code: 
2022-10-22 21:10:34.429 sogod[23999:100327] File NSDictionary.m: 672. In -[NSDictionary initWithContentsOfFile:] Contents of file '/usr/local/etc/sogo/sogo.conf' does not contain a dictionary
Also how do you trigger the bug ? (url?)

edit: I googled around and found an Arch setup for pgsql. I've googled around for that error, it seems that whole config has to be embedded in braces {}. How do you trigger the bug then?
edit2: well, pgsql is spitting lots of errors , I guess I need some additional tables in that db. Can you share that ?
 
You are right, sorry for the confusion - I have reinstalled from binary package, and the checksum now also matching the pkg list output:
Code: 
# cksum /usr/local/GNUstep/Local/Library/Libraries/sogo/libSOGo.so.5
427534641 1068600 /usr/local/GNUstep/Local/Library/Libraries/sogo/libSOGo.so.5

Did you copy the /usr/local/etc/sogo/sogo.conf.sample to /usr/local/etc/sogo/sogo.conf and then add the specific settings? Otherwise the error might be because the start and ending curly brackets around the settings are missing in what I posted.

Some details about db can be found here in the Installation Guide:
https://www.sogo.nu/files/docs/SOGoInstallationGuide.html#_database_configuration

If I remember correctly, I only added the sogo user, and created the sogo_view table and inserted user credentials manually like this:
Code: 
CREATE TABLE sogo_view (c_uid VARCHAR(10) PRIMARY KEY, c_name VARCHAR(10), c_password VARCHAR(32), c_cn VARCHAR(128), mail VARCHAR(128));
INSERT INTO sogo_view VALUES ('jdoe', 'jdoe', MD5('zxc'), 'John Doe', 'jdoe@example.com');

The bug is triggered when I try to login with correct credentials on https://hostname/SOGo, and service responds with Unhandled error response.
 
One of those facepalm moments where I used the VM I had free but already had jail in it with apache I forgot about:) That's why I was struggling to get it work - port 80 was redirected to jail.

Now I'm able to trigger the bug. First glance at it with debugger shows that canary is cut short one byte, possibly off-by-one bug. As I had some :beer:as I was waiting I won't do it today (too late already).
 
I found the issue. It was off by one as I've expected. But I didn't think it would be in the place where it was. I did open a bugreport on their official tracking system. I'm absolutely unfamiliar with the objective-c so I wonder what they'll say. I found the docs about objective-c @ apple web page, not sure how valid that is in general.

But the problem is in decodeDataFromHexString():
Code: 
..
unsigned char srcBuffer[stringLength];
[theString getCString:(char *)srcBuffer];
unsigned char *srcPtr = srcBuffer;
..
According to apple docs older version of getCString() required NULL byte, newer doesn't. I have no idea how to interpret that information and how one knows where new version is used. But..

On Linux stack canary has null byte in, on FreeBSD it doesn't. On most Linux systems this issue can be undetected as 0 is rewritten by 0. Not true here.
I've created a small patch and tested it on port version, it works ok. If you unzip and save the patch to /usr/ports/www/sogo-activesync/sogopatch.unof and do:
Code: 
cd /usr/ports/www/sogo-activesync
make clean && make patch
patch -p1 < sogopatch.unof
make install clean
You'll get it running ok.
 

Attachments

  • sogopatch.unof.zip
    446 bytes · Views: 58
Thanks. I actually went through the trouble of reporting it here but nobody cared to reply.
There are open Q on the behavior of that function but 🤷
 
You must log in or register to reply here.
Back
Top