1

I've posted this over at ServerFault but haven't received a response over there. I'm not a security professional, but I'm curious as to what kind of attack this might be and how the attackers might be performing it. I figured someone here who's more knowledgeable in security might know.

Here's the text of the original post:

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=400 00003 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.

I should add that I'm using OpenSSH 6.7p1 and Linux kernel version 3.18.12.

  • 3
    I'm voting to close this question for two reasons: 1) It's cross posted. 2) I think a better response might come from tech forums where a discussion can be had. – RoraΖ Dec 18 '15 at 16:18
3

Solved on ServerFault and in upstream. Pushing also here to mark as solved.

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. 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.

  • The second can be safely allowed from my point of view as well. The getpgid() syscall is completely safe. It takes a single PID as an argument, and only returns the PGID (the PID of the process group leader) in the eax or rax register, so even if it's a bug, it has no exploitation potential, and extremely low infoleak potential (PIDs are not meant to be secret). – forest Apr 24 '16 at 5:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.