I can't guarantee that this is not true, but our testing group did look into it and can't duplicate the error. It appears instead that this is simply a trick to get you to run the suggested patch. Please don't do that as it did not come from Ipswitch. We are still trying to determine exactly what the patch will really do to you.
John CTO, Ipswitch. In reply to 27 Jul message from [EMAIL PROTECTED]: >I'm surprised there's been no discussion here of something this big >--- ALL OF US WERE WIDE OPEN AND THE BAD GUYS KNOW ABOUT IT. > You need to know so you can make the decision to shut down web >messaging and calendaring (which certainly would have the same >problem), or patch it with a firewall by blocking packets containing >non-ascii characters. I haven't posted the exploit or patch. I >wouldn't trust the patch from someone who does not responsibly >disclose bugs - not to mention that the patch is applied in an unsafe >manner. I'm off with a disassembler to check it out though. > -------------------- Original message >--------------------------------- >"In 1995, Ipswitch released IMail Server, the first commercial NT >Mail Server. Seven years later there are over 49 million users of >IMail worldwide. >IMail Server 7.1 >Greater security, improved usability, and new revenue opportunities >for service providers." >7 years in development, 20 minutes of BuffSex >v0.3(tm), 3 remote 'root' holes >2c79cbe14ac7d0b8472d3f129fa1df55 Security Advisory #5 >#PRODUCT >IPSwitch IMail, All Versions >#VULNERABILITY >there is an overflow present in the GET parameter >under the HTTP/1.0 specification in the Web Messaging daemon in all >IMail versions to date.. HTTP/0.9 & >HTTP/1.1 are not vulnerable, as they have been fixed in a previous >bug report.. oops, forgot one :> >#EXPLOITATION ><96 bytes><EBP><EIP> >choosing right causes no problems, soooo.... >as none of the registers point to our payload on ret some trickery is >necessary to hit our payload in a dynamic way.. nothing too difficult >however >esp is 8 bytes from our payload, but it has to run right over our >chosen ret (call/jmp esp).. so flat out jmping esp has some shitty >near-impossible odds >working against it.. so we need to do some sex first >execution flow: >eip overran, ret (esp-4) -> (imailsec.dll) land at pop ebx, ret10 >(esp-18) -> (imailsec.dll) call esp >after only 3 redirections we've now got esp pointing at our corrupted >payload.. YUMMY! >preserve esp -> sub esp -> jmp esp >we preserve esp to prevent our stack from running >right over our code, then we jump relative to our good payload.. >ooohh you know whats coming next >recover esp -> execute shell >now that the stack is out of the way, we can just let the shit fly.. >see attached exploit.. target imail version is 7.11 (HF1 applied or >not) >#PATCH >since this is just a simple buffer overflow >(lstrcpya() if I remember correctly?), a simple patch is in order!.. >GET argument is now limited to 90 >characters, we can assume no more is necessary, as someone else would >have found this earlier.. >#EOF >mailserver #4, more to come.. >always, >2c79cbe14ac7d0b8472d3f129fa1df55 >Please visit http://www.ipswitch.com/support/mailing-lists.html to be >removed from this list. >An Archive of this list is available at: >http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ >Please visit the Knowledge Base for answers to frequently asked >questions: http://www.ipswitch.com/support/IMail/ Please visit http://www.ipswitch.com/support/mailing-lists.html to be removed from this list. An Archive of this list is available at: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Please visit the Knowledge Base for answers to frequently asked questions: http://www.ipswitch.com/support/IMail/
