4,620
edits
Changes
→System Modules
| January 30, 2023
| January 30, 2023
| February 26, 2023
| February 26, 2023
| [[User:Yellows8|yellows8]]
|-
| [[NS_services|ns]] RequestMoveApplicationEntity/EstimateSizeToMove buffer overflow
| ns RequestMoveApplicationEntity eventually calls a func which: Loops through the input buffer. If any entry has value 6, it will call another func to copy data from state to output safely (uses the max_count param). Otherwise, it copies the input buffer to an outbuf (located on caller's stack) without any size validation (inlined memcpy), even though there is a max_count param.
Additional memwrites are also done to the above outbuf following the initial memcopy. This can be avoided if the buffer doesn't contain bytes with values 3-6 (if using values in that range is really needed, the cmd input StorageId param can be set to the required value so that the specified value doesn't trigger the memwrite). Value 6 shouldn't be used anyway (see above).
ns EstimateSizeToMove first calls the same func which does the copy above (outbuf is also located on stack), then it calls another func. Hence, same vuln here.
By corrupting just the first byte of x29 with EstimateSizeToMove, one can obtain infoleaks. This method with x29 essentially only works with [15.0.0+]. Pre-15.0.0 would require a different method with partial overwrite of retaddr, however it's unknown whether this would actually work for infoleak (would require [12.0.0+] for the stack layout change).
With EstimateSizeToMove where x29 is overwritten, the output u64 is the leaked ptr (can be codebin-region). Note that the cmd has to return Result=0 for this to work. x29 is used to load the value which is copied to the cmdreply rawdata.
As of [17.0.0+] an error is thrown if the input array count is larger than 8 (size of the stack dst-array).
| ns-sysmodule stack buffer overflow, allowing ns infoleak+ROP.
| [[17.0.0]]
| [[17.0.0]]
| January 2, 2023
| October 17, 2023
| [[User:Yellows8|yellows8]]
| [[User:Yellows8|yellows8]]
|}
|}