Local buffer too small to hold opaque_auth data in svcauth_gss_validate?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Local buffer too small to hold opaque_auth data in svcauth_gss_validate?

Tomas Kuthan
Hi,

src/lib/rpc/svc_auth_gss.c:
293 static bool_t
294 svcauth_gss_validate(struct svc_req *rqst, struct svc_rpc_gss_data
*gd, struct rpc_msg *msg)
295 {
296 struct opaque_auth *oa;
297 gss_buffer_desc rpcbuf, checksum;
298 OM_uint32 maj_stat, min_stat, qop_state;
299 u_char rpchdr[128];
...
307 oa = &msg->rm_call.cb_cred;
308 if (oa->oa_length > MAX_AUTH_BYTES)
309 return (FALSE);
310
311 /* 8 XDR units from the IXDR macro calls. */
312 if (sizeof(rpchdr) < (8 * BYTES_PER_XDR_UNIT +
313      RNDUP(oa->oa_length)))
314 return (FALSE);
...

As a part of MIC verification, opaque_auth data is copied into local
variable rpcbuf. According to a comment in src/include/gssrpc/auth.h,
opaque_auth size can be up to MAX_AUTH_BYTES=400, but the local buffer
only has 128 B.

This feels unnecessarily limiting. At least since CVE-2007-3999 there is
no buffer overflow (lines 311-314), but still, it seems some valid
messages might get rejected just because their size exceeds 128.

Is there a reason for having the local buffer be 128 B only?

Thanks,
Tomas
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Local buffer too small to hold opaque_auth data in svcauth_gss_validate?

Greg Hudson
On 09/22/2016 04:45 AM, Tomas Kuthan wrote:
> 299 u_char rpchdr[128];
>
> This feels unnecessarily limiting. At least since CVE-2007-3999 there is
> no buffer overflow (lines 311-314), but still, it seems some valid
> messages might get rejected just because their size exceeds 128.
>
> Is there a reason for having the local buffer be 128 B only?

I have no specific insight into this code, which is really old.  What
goes into opaque_auth data?  (I looked through the code, but it wasn't
obvious.)  Is this restriction creating a practical problem?
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Local buffer too small to hold opaque_auth data in svcauth_gss_validate?

Tomas Kuthan
On 09/23/16 19:12, Greg Hudson wrote:

> On 09/22/2016 04:45 AM, Tomas Kuthan wrote:
>> 299 u_char rpchdr[128];
>>
>> This feels unnecessarily limiting. At least since CVE-2007-3999 there is
>> no buffer overflow (lines 311-314), but still, it seems some valid
>> messages might get rejected just because their size exceeds 128.
>>
>> Is there a reason for having the local buffer be 128 B only?
>
> I have no specific insight into this code, which is really old.  What
> goes into opaque_auth data?  (I looked through the code, but it wasn't
> obvious.)  Is this restriction creating a practical problem?
>

Hi Greg,

thank you for looking into it.

What goes into opaque_auth data is unclear to me too. There are code
comments on various places, that suggest it is "raw credentials".
But when I dig into Solaris RPCSEC_GSS flavor code, it looks there is
just a handle for creds stored elsewhere. I suppose it is security
flavor dependent...

I am not aware of a practical problem caused by this. I started looking
into it, when this code was flagged as a (false positive) buffer
overflow by a static analysis tool.

I'd say there is a theoretical potential for a bug here, as this code
cannot put up with MAX_AUTH_BYTES of opaque_data, as it should, but it
is possible no flavor actually uses opaque_data too big to fit.

I am wild about pro-actively 'fixing' this and risking breakage
elsewhere. What do you think?

Thanks,
Tomas
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev