1

I'm seeing strange entries for sshd in my audit logs along the lines of:

type=SECCOMP audit(1433519794.902:46): auid=20003 uid=22 gid=22 ses=21 pid=25136 comm="sshd" exe="/usr/sbin/sshd" sig=31 arch=40000003 syscall=102 compat=0 ip=0xb76c8aac code=0x0
type=SECCOMP msg=audit(1433785727.186:10262): auid=20003 uid=22 gid=22 ses=21 pid=11217 comm="sshd" exe="/usr/sbin/sshd" sig=31 arch=40000003 syscall=132 compat=0 ip=0xb7670aac code=0x0

Anyone have any idea what's happening? My guess is that, OpenSSH forks a sandboxed process for preauth and someone is attempting to execute system calls (socketcall and getpgid) during this connection phase.

All connections appear to come from Korea.

Gilles 'SO- stop being evil'
  • 9,391
  • 1
  • 33
  • 48
Robert
  • 23
  • 5
  • Which OS is this? `SECCOMP` sounds like Linux, but I haven't seen that log anything. It would just silently kill processes attempting system calls which were not permitted. – kasperd Dec 20 '15 at 18:42

1 Answers1

1

The meaning of syscall you can find out simply by executing:

$ ausyscall 102
socketcall
$ ausyscall 132
getpgid

The first one is upstream bug, now fixed (reported [1]). ix86 is using this system call to shutdown socket (close one way).

The second looks like problem of packaging or some downstream patch (what distribution are you using?), because this can be safely allowed from my point of view -- we were allowing getpid and similars for auditing purposes.

To cool you down, no security concern here :) This is probably happening with every (failed) connection.

[1] https://bugzilla.mindrot.org/show_bug.cgi?id=2361#c14

Jakuje
  • 9,715
  • 2
  • 42
  • 45
  • I'm running Gentoo. I quickly glanced over their supplied patches and didn't see anything calling getpgid directly, but maybe it's being triggered elsewhere. They use the HPN patch and a few other miscellaneous patches. – Robert Jun 26 '15 at 19:31
  • It looks like openssh is using this to one after grace time expires: https://github.com/openssh/openssh-portable/blob/51a1c2115265c6e80ede8a5c9dccada9aeed7143/sshd.c#L368 It is possible it should be also included in filter as acceptable call. I will investigate it further on Monday. – Jakuje Jun 27 '15 at 19:16
  • I can't reproduce it with current version (6.8) we ship in Fedora but I clearly see that this is in source code. I reproduced this only when I turned off gcc optimization so it is probably optimized out -- I will post upstream link here later. – Jakuje Jun 29 '15 at 12:51
  • Filled upstream bug: https://bugzilla.mindrot.org/show_bug.cgi?id=2419 – Jakuje Jun 29 '15 at 13:12