![]() ![]() ![]() Please note that this workaround may have an additional impact on users or operational systems that expect CONFIG SET to behave in certain ways. Using older versions, the rename-command configuration directive can be used to rename the command to a random string unknown to users, rendering it inaccessible.Using Redis 6.0 or newer, ACL configuration can be used to block the command.WorkaroundsĪn additional workaround to mitigate the problem without patching the redis-server executable is to prevent clients from directly executing CONFIG SET: Make sure you use one of these versions if you're running 32-bit Redis. The problem is fixed in version 6.2, and the fix is back ported to 6.0.11 and 5.0.11. This problem only affects 32-bit Redis (on a 32-bit system, or as a 32-bit executable running on a 64-bit system). We believe this could in certain conditions be exploited for remote code execution.īy default, authenticated Redis users have access to all configuration parameters and can therefore use the “CONFIG SET proto-max-bulk-len” to change the safe default, making the system vulnerable. If the limit is significantly increased, receiving a large request from a client may trigger several integer overflow scenarios, which would result with buffer overflow and heap corruption. By default, it is 512MB which is a safe value for all platforms. Redis 4.0 or newer uses a configurable limit for the maximum supported bulk input size. I know FreeRTOS has to work even on some horrible dinosaur compilers that can’t handle “static inline” functions, and therefore still uses outdated macro styles, but we’ll ignore that here.An integer overflow bug in 32-bit Redis version 4.0 or newer could be exploited to corrupt the heap and potentially result with remote code execution. To make the types clearer, use “static inline” functions rather than function-like macros. So if you are going to define macros like timeAfter, then do it right. Usually it works as you expect, but not always – and the compiler can take advantage of the undefined behaviour (according to C standards) to generate smaller and faster code, even though it does not work as you expect. One thing that is missing from this discussion is to understand that signed integer overflow and wrap is undefined in C. With a more realistic 32-bit tick these are straightforward conditions to meet.Ī similar macro is used in the Linux Kernel (as time_after in jiffies.h) the above example is safe if SOME_SHORT_PERIOD is less than 127 and the test happens soon/often enough. If (timeAfter(timeNow(), alarm)) do_something() Īs noted, the disambiguation period is half the maximum tick value, i.e. The intended usage is situations such as: But that’s not the question the problem is to determine whether a is after b.Įssentially, (assuming 8-bit ticks for ease) we want a function that evaluates as true with the following arguments: (1,0), (2,1), (128,127), (255,254), (0,255) and false if the arguments are reversed. If a is known to be after b then, using unsigned arithmetic, (a – b) does indeed give the correct time difference even if a has overflowed. That works until a overflows, but fails to give the desired answer if a has overflowed but b hasn’t. The problem is to determine if one time is “after” another (not to find the difference between them). * The disambiguation window is half the maximum value. * using signed arithmetic automatically handles wrapping. * Times a and b are unsigned, but performing the comparison * Determine if time a is "after" time b. In case it helps anyone else, below is the macro that I am using: It turns out that it is surprisingly easy to correctly do a comparison that will correctly handle wraparound, just by casting the unsigned tick counts to signed. Overflows must however be considered by host applications if the application makes direct use of the tick count value. This will not effect the internal operation of the kernel for example, tasks will always block for the specified period even if the tick count overflows while the task is in the Blocked state. The tick count will eventually overflow and return to zero. In the section describing the xTaskGetTickCount function, the FreeRTOS reference manual says:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |