From: Jim S. <ja...@ne...> - 2004-03-13 23:35:52
|
Samofatov, Nickolay wrote: >My current codebase produces 5 warnings resulting from lack of wisdom of >GCC developers (no way to locally disable warning that comparison is >always true/false due to limited range of data type) and a handful >warnings in cch.cpp due to lack of wisdom of C++ committee (offsetof is >undefined for all non-POD datatypes, even very simple ones). > Isn't that annoying? And really stupid. It's what comes from committees designing language. Those are also the only warning in Netfrastructure, and every other database in the world with a variable page size. > >Anyway, when I did 64-bit GCC build with aggressive warnings options >compiler barked at security issue in server.cpp:aux_connect. >Basically packet with opcode op_aux_connect receives pointer over the >wire and writes data at its location. This is easy-to-exploit DoS issue >at the very least. > >The aux_connect routine is a part of secondary attachments >infrastructure and current codebase doesn't provide means to send >op_aux_connect packet. >It was used only for Apollo server if I understand IB6 codebase >correctly. > I think you missed something. It exists to establish a secondary connection for event handling, and is probably used in all ports. I agree that the original implementation is dangerous. And, of course, it is mine. It could be easily (and transparently) repaired by sending context specific handles rather pointers. Since the far end just sends back whatever was sent, this is completely safe. If you'd like, you'll find a Vulcan class HandlerManager which would do the thing. It's in Vulcan, but I have used it yet, so please let me know about the gaffs. |