|Summary:||Integer overflow in ffs_setextattr() could lead to a kernel heap overflow|
|Product:||Base System||Reporter:||Tommaso <cutesmilee.research>|
|Component:||kern||Assignee:||freebsd-bugs (Nobody) <bugs>|
|Status:||Closed Not A Bug|
|Severity:||Affects Many People||CC:||chris, markj|
Description Tommaso 2021-04-10 22:05:22 UTC
ffs_setextattr() is used to set a named attribute to an ffs vfs. the problem is that it takes some user controlled data, the interesting ones are: ap->a_name (arbitrary user string, not checked), and ip->i_ea_len (unsigned int), which also isn't checked. the function uses ip->i_ea_len + ealength (which is 7 + strlen(ap->a_name)) for allocating a buffer, after that user-controlled data are copied to the buffer using ip->i_ea_len. providing an INT_MAX ip->i_ea_len + 2^32 + 2 long string will cause an integer overflow, and the buffer in the heap will be 1 byte, but the bcopy will copy 2^32 bytes to the buffer. this should be reachable from an unprivileged user (since extattr_check_cred() doesn't require root if the attrnamespace is set to EXTATTR_NAMESPACE_USER), but seems to be difficult to exploit, since you'd need 4GBs of ram (for the long string) just to perform the 2^32 heap overflow, an exploitable overflow will probably take even more memory.
Comment 1 Mark Johnston 2021-04-12 12:50:01 UTC
The attribute name length is checked by callers of the VOP, or is not user-controlled to begin with. Callers of extattr_set_vp(), for example, will provide a string of length at most EXTATTR_MAXNAMELEN == NAME_MAX. We should perhaps assert this limit in ffs_setextattr(). ip->i_ea_len is not directly user-controlled, it is the size of the extattrs for the inode represented by ip. The space reserved for extattrs is limited to two blocks and ffs_setextattr() checks this. I may well be missing something - do you have a test case to demonstrate the problem?
Comment 2 Tommaso 2021-04-12 12:54:24 UTC
unfortunately I haven’t, from my static analysis I haven’t noticed the name length check, so I probably missed something. anyway since you’re here, I’ve reported another bug a week ago, but I haven’t received any news about it, could you provide me some infos about it? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254737 that’s it.