Bad bug in remote logging

Bad bug in remote logging

[Steve Grubb]

Hello,

There was a bug reported to day that I think merits an email and/or discussion.

https://bugzilla.redhat.com/show_bug.cgi?id=695419
=================================
audisp-remote does
>               memset (&address, 0, sizeof(address));
>               address.sin_family = htons(AF_INET);
>               address.sin_port = htons(config.local_port);
>               address.sin_addr.s_addr = htonl(INADDR_ANY);
which shows in strace as

> bind(3, {sa_family=0x200 /* AF_??? */, sa_data="\0<\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 
0

For some reason the call still succeeds, but a correct invocation would not
call htons on AF_INET.
================================

The reason it succeeds is because there is a matching mistake in auditd. So, what this 
means is that remote logging is not using IPv4, but something else. I committed a 
patch to fix this in trunk:

https://fedorahosted.org/audit/changeset/505

This would cause new systems and old systems to not be able to talk to one another. 
Regarding RHEL, remote logging has been tech preview, meaning that its alpha code and 
likely buggy but available so you can see where this is heading. So, I think we can 
just change it to be correct. For Fedora, there is no tech preview and everything is 
supported...but it has a short life. However, what the code was doing is clearly 
wrong. So, I am thinking to fix this all the way back to F-13 if I can. Regarding other 
distributions...not sure what the support status is or how they would like to choose 
to solve this. Anyone have any thoughts on this?

-Steve

Re: Bad bug in remote logging

[Linda Knippers]

Steve Grubb wrote:
> Hello,
> 
> There was a bug reported to day that I think merits an email and/or discussion.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=695419
> =================================
> audisp-remote does
>>               memset (&address, 0, sizeof(address));
>>               address.sin_family = htons(AF_INET);
>>               address.sin_port = htons(config.local_port);
>>               address.sin_addr.s_addr = htonl(INADDR_ANY);
> which shows in strace as
> 
>> bind(3, {sa_family=0x200 /* AF_??? */, sa_data="\0<\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 
> 0
> 
> For some reason the call still succeeds, but a correct invocation would not
> call htons on AF_INET.

Are you sure that that field is actually used by bind()?  Doesn't the
socket also have the address family?  Its surprising that the call would
succeed and even more surprising that the socket would work.

> ================================
> 
> The reason it succeeds is because there is a matching mistake in auditd. So, what this 
> means is that remote logging is not using IPv4, but something else. 

What else would it be using?  That value is greater than any legal 
address family so I would think that lots of things in the kernel
would break.

> I committed a 
> patch to fix this in trunk:
> 
> https://fedorahosted.org/audit/changeset/505
> 
> This would cause new systems and old systems to not be able to talk to one another. 
> Regarding RHEL, remote logging has been tech preview, meaning that its alpha code and 
> likely buggy but available so you can see where this is heading. So, I think we can 
> just change it to be correct. For Fedora, there is no tech preview and everything is 
> supported...but it has a short life. However, what the code was doing is clearly 
> wrong. So, I am thinking to fix this all the way back to F-13 if I can. Regarding other 
> distributions...not sure what the support status is or how they would like to choose 
> to solve this. Anyone have any thoughts on this?

Your resolution seems ok if this is really more than a benign coding
problem.

-- ljk

> 
> -Steve
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

Re: Bad bug in remote logging

[Stephan Mueller]

Am Dienstag, 12. April 2011, um 05:18:44 schrieb Linda Knippers:

Hi Linda,

> Steve Grubb wrote:
> > Hello,
> > 
> > There was a bug reported to day that I think merits an email and/or
> > discussion.
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=695419
> > =================================
> > audisp-remote does
> > 
> >>               memset (&address, 0, sizeof(address));
> >>               address.sin_family = htons(AF_INET);
> >>               address.sin_port = htons(config.local_port);
> >>               address.sin_addr.s_addr = htonl(INADDR_ANY);
> > 
> > which shows in strace as
> > 
> >> bind(3, {sa_family=0x200 /* AF_??? */,
> >> sa_data="\0<\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) =

Bind does not do anything with the family - it just calls the bind callback 
function set for the protocol by the socket syscall. What is the socket 
syscall saying here?

Note that the socket syscall (specifically __sock_create) has the following 
code for the family:

        if (family < 0 || family >= NPROTO)
                return -EAFNOSUPPORT;

And NPROTO is defined as decimal 39 (in 2.6.38). Hence, 0x200 as a family does 
not work for socket - the socket syscall would have returned an error.

If for some reason the socket syscall uses AF_INET and diverts into IPv4, 
sin_family does not seem to be used unless you have a socket-specific bind 
function (e.g. RAW sockets).

To make a final determination on the impact, I would check:

- strace for socket syscall

- tcpdump on the connection

Ciao
Stephan

Re: Bad bug in remote logging

[Steve Grubb]

On Tuesday, April 12, 2011 03:23:08 AM Stephan Mueller wrote:
> Am Dienstag, 12. April 2011, um 05:18:44 schrieb Linda Knippers:
> 
> Hi Linda,
> 
> > Steve Grubb wrote:
> > > Hello,
> > > 
> > > There was a bug reported to day that I think merits an email and/or
> > > discussion.
> > > 
> > > https://bugzilla.redhat.com/show_bug.cgi?id=695419
> > > =================================
> > > audisp-remote does
> > > 
> > >>               memset (&address, 0, sizeof(address));
> > >>               address.sin_family = htons(AF_INET);
> > >>               address.sin_port = htons(config.local_port);
> > >>               address.sin_addr.s_addr = htonl(INADDR_ANY);
> > > 
> > > which shows in strace as
> > > 
> > >> bind(3, {sa_family=0x200 /* AF_??? */,
> > >> sa_data="\0<\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) =
> 
> Bind does not do anything with the family - it just calls the bind callback
> function set for the protocol by the socket syscall. What is the socket
> syscall saying here?

The socket call is correct.
socket (AF_INET, SOCK_STREAM, 0);


> Note that the socket syscall (specifically __sock_create) has the following
> code for the family:
> 
>         if (family < 0 || family >= NPROTO)
>                 return -EAFNOSUPPORT;
> 
> And NPROTO is defined as decimal 39 (in 2.6.38). Hence, 0x200 as a family
> does not work for socket - the socket syscall would have returned an
> error.
> 
> If for some reason the socket syscall uses AF_INET and diverts into IPv4,
> sin_family does not seem to be used unless you have a socket-specific bind
> function (e.g. RAW sockets).

It seems that bind(2) is not using the family. I checked on a system that is fixed vs 
one that is not fixed. They both can transfer packets to one another. So, it looks like 
you are right and there is only cosmetic problem.
 
> To make a final determination on the impact, I would check:
> 
> - strace for socket syscall
> 
> - tcpdump on the connection

These seem to be OK aside from strace not being able to decipher the family member to 
bind. However, the calls to bind and connect are successful.

-Steve