Re: [Full-Disclosure] Windoze almost managed to 200x repeat 9/11
Well Put. Regards, Nancy Kramer Webmaster http://www.americandreamcars.com Free Color Picture Ads for Collector Cars One of the Ten Best Places To Buy or Sell a Collector Car on the Web At 11:15 AM 9/24/2004, Barry Fitzgerald wrote: Frank Knobbe wrote: On Fri, 2004-09-24 at 09:15, Barry Fitzgerald wrote: The article doesn't make the situation entirely clear. Did the app intentionally restart the system and foul it? Did the restart occur because the app crashed? No, no, the problem was human error because a tech didn't reboot the system. It's clearly operator error, not a problem with any systems at all. I disagree - if the system were engineered properly, a reboot would not be necessary to keep the system from falling on it's face. The article implied (though didn't outright state it) that the Unix systems did not include regular reboots. I don't know enough about the engineering of the system to state whether this was caused by the app, the OS, or some dependancy issue. But, in a critical system of this nature, relying on scheduled reboots for operation sends a signal to me that there's a problem in the system. Unfortunately, there is some truth in this. We (and not just the media) are starting to put blame on humans far too quickly. Is this justified? On one hand, they are only tools for us to do our job. On the other hand, they are products that we should be able to rely on. Who do we blame? Operators or products? That depends on the situation. If a system can be engineered to operate properly on it's own, then it should be. All else is operator error. I think it most depends on the rationality of the automated requirement. If the backup fails because said user forgets to change the backup tapes, then the problem is human error. If the backup fails because said product doesn't properly flush its buffers and sends all data to /dev/null, then the issue is software error, even if it's a known condition that has had procedure put in place to work around it. The argument for automation is rational and supposed to be in the system, and thus it's an error in the engineering. The second scenario is similar to what we had here. All a reboot does is ensure that the memory has been cleared. If their developers don't know how to do this in code, or if they choose OS' that can't reliably do this, then either fire the developers and/or the decision makers, because they didn't do their jobs and people could have died because of that. -Barry ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.767 / Virus Database: 514 - Release Date: 9/21/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.769 / Virus Database: 516 - Release Date: 9/24/2004
Re: [Full-Disclosure] Rootkit For Spyware? Hide your adware from all Adware removers and Anti-viruses
Thanks for the interesting reading Mike. =) Good stuff there. -- Peace. ~G On Sat, 25 Sep 2004 00:08:19 -0500 (CDT), Mike Barushok [EMAIL PROTECTED] wrote: Back in the day, 1994 to be exact, there was a virus that with the commonly available tools was quite difficult to eliminate, and which was usually detected by effects rather than the presence on disk, or in main memory. One of the effects it had was to delete or stops the execution of programs called SCAN, CLEAN, NETSCAN, CPAV, MSAV, TNTAV. Actually many other executables other than those were interfered with also. Another effect was a system with a modem would start answering on the seventh ring. And it deleted files named 'CHKLIST.*' (defeating integrity checking, but noticeable). Had it been truly polymorphic, less 'noisy', and with several modern tricks, it could initially have been credibly described as almost undetectible. Erasing the CMOS memory could have seemed like a dead battery. Checkout GOLDBUG, see: http://www.f-secure.com/v-descs/goldbug.shtml http://www.textfiles.com/virus/gold-bug.txt http://vx.netlux.org/lib/static/vdat/retrovir.htm For all intents and purposes anything you would expect the system to do under certain circumstances, can be subverted such that the expected result would be generated falsely. File scanning, registry keys and values, process enumeration, could all be made to appear to suceed in finding nothing out of the ordinary. Windows regedit is well known to hide some of the key names and their values. Disk areas other than the 'file system' can hold data. Processes that are already always running (like Kernel32 itself, could be the process that was modified to do the dirty deeds. Generally, with any general purpose computer, the ability to trust the results of any particular action depend on fully knowing the complete state of the machine. So, a machine in an unknown state cannot verify itself to be in an 'expected' state. Additionally, it is theoretically feasible to modify the CPU's microcode to alter execution of already present software as desired. This was mentioned as far back as twenty years ago by someone who instead demonstrated a trojan that worked by modifying the Unix login, when the login program was compiled, and that detected a new version of the compiler being compiled and replicated itself to the new compiler object code. See: K. Thompson. Reflections of Trusting Trust, Communication of the ACM, Vol. 27, No. 8, Aug 1984, pp. 761-763. http://www.acm.org/classics/sep95 He stated You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me). No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well installed microcode bug will be almost impossible to detect. So, although I doubt that any company is really selling any completely undetectible code, for the purposes being discussed in this thread, there almost certainly is some very difficult to detect software already being used for other purposes important to certain three-letter-agencies. On Thu, 23 Sep 2004, GuidoZ wrote: It is quite possible to hide processes, reg keys and files, and is often done by various malware. Aye. I didn't word my statements correctly. (Was tired... =P ) You are very much correct. I guess I was trying to speak along the lines of AV detection and forensics. I've yet to find a rootkit, spyware, or malware that is COMPLETLY hidden, in every aspect, from the user. There is always a way to find it. Granted, they can bypass the usual means (regedit, taskmanager, etc) in Windows, however there are specialized tools (process viewers for example) that show hidden processes. What I meant to express is they seem to claim being able to hide from everything. (Even if an AV solution detected the very program they use as an installer.) That, I doubt. To save someone else from saying this, I'll reply to my own comment. =) I've yet to find a rootkit, spyware, or malware that is COMPLETLY hidden, in every aspect, from the user. Well, DUH. How could you find it if it was COMPLETELY hidden? ;) Clarification: The user and a sysadmin that has a clue are two very different people.) -- Peace. ~G On Thu, 23 Sep 2004 14:38:34 +1000, Matt [EMAIL PROTECTED] wrote: GuidoZ wrote: Interesting indeed. Although, I imagine this was a spam email, and I never believe (nor buy) anything from spam. I wondr how credible this really is. If there was such a way to do what they claim, don't you think it would have
Re: [Full-Disclosure] Strange FTP log messages
Andrea Purificato - bunker wrote: Alle 16:08, venerdì 24 settembre 2004, ken ha scritto: Does anyone recognize this behavior? This has been occurring for a while. I am curious as to what would cause this. This has been happening on a wide range of IPs. Any hints would be appreciated, thanks in advance. Well I did a WHOIS and got tthe following result from that putative IP number. Now remember it has been years since I did lots of this sort of stuff. ...but I am pretty sure the info is correct. ...NSLOOKUP seems to confirm most of it. You can send them mail and ask them what them are uip to doing. If I had more sleep and had not spent so much time looking at weather maps and old such strange stuff it might immediately dawn on me as to what is up. But I really need to sleep.hope that starts you on your way. 205 /u/chroma whois 65.82.31.47 [Querying whois.arin.net] [whois.arin.net] OrgName:BellSouth.net Inc. OrgID: BELL Address:575 Morosgo Drive City: Atlanta StateProv: GA PostalCode: 30324 Country:US ReferralServer: rwhois://rwhois.eng.bellsouth.net:4321 NetRange: 65.80.0.0 - 65.83.255.255 CIDR: 65.80.0.0/14 NetName:BELLSNET-BLK9 NetHandle: NET-65-80-0-0-1 Parent: NET-65-0-0-0-0 NetType:Direct Allocation NameServer: NS.BELLSOUTH.NET NameServer: NS.ATL.BELLSOUTH.NET Comment: Comment:For Abuse Issues, email [EMAIL PROTECTED] NO ATTACHMENTS. Incl IP Comment:address, time/date, message header, and attack logs. Comment:For Subpoena Request, email [EMAIL PROTECTED] with SUBP A in Comment:the subject line. Law Enforcement Agencies ONLY, please. RegDate:2000-11-28 Updated:2003-05-05 AbuseHandle: ABUSE81-ARIN AbuseName: Abuse Group AbusePhone: +1-404-499-5224 AbuseEmail: [EMAIL PROTECTED] TechHandle: JG726-ARIN TechName: Geurin, Joe TechPhone: +1-404-499-5240 TechEmail: [EMAIL PROTECTED] OrgAbuseHandle: ABUSE81-ARIN OrgAbuseName: Abuse Group OrgAbusePhone: +1-404-499-5224 OrgAbuseEmail: [EMAIL PROTECTED] OrgTechHandle: JG726-ARIN OrgTechName: Geurin, Joe OrgTechPhone: +1-404-499-5240 OrgTechEmail: [EMAIL PROTECTED] # ARIN WHOIS database, last updated 2004-09-24 19:10 # Enter ? for additional hints on searching ARIN's WHOIS database. 206 /u/chroma Have Fun, Sends Steve ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] MS04-028 Jpeg EXPLOIT with Reverse and Bind shell ...
the last step before the worm http://www.k-otik.com/exploits/09252004.JpegOfDeath.c.php Do you Yahoo!?vote.yahoo.com - Register online to vote today!
Re: [Full-Disclosure] MS04-028 Jpeg EXPLOIT with Reverse and Bind shell ...
ElviS .de wrote: the last step before the worm http://www.k-otik.com/exploits/09252004.JpegOfDeath.c.php Are securepoint giving away consultancy jobs for the first working implementation this time ? ;) ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Windoze almost managed to 200x repeat 9/11
What seems to read clearly from your replies to this thread is that either; 1 the code was better done under the original OS, unix The system was different, although it is likely that the (designed/intended) functionality is identical. Some older Unixes are no longer supported both by hardware and by professionals; this is a problem for supporting old mission critical apps. The need for a changeover is not uncommon in closed unit systems of this type; and the newer apps rarely cut the mustard (often due to poor coding and over complication of the system). High quality code is a product of the coder, not the operating system. 2 considering how often you seems to run into this same issue with other coders in the windows realm, windows coders tend to be especially lazy/clueless as compared to coders in other OS' This is possibly true, but you may well find that this correlated back to the whole usage of WYSIWYG OS and design tools and the general non tech nature of the average windows user. It is also possible that the IDE in use can also contribute to reduced reading of proper API documents which leads to errors of this sort due to their ease of use and a lack of attention to detail on the programmers side. Poor quality assurance practices are what leave this kind of error unnoticed (least we not forget however that this error WAS noticed and documented). Once again however, the type of people that gravitate to a type of OS is what causes your (general) differences in skill levels. This is not correlated directly to what you should get in terms of a development team for such an important application. Using Windows will not make you a bad coder; not reading documentation will. You could code the same application in Java and in much the same way and you would end up with a runtime error; typically however a Java based system would warn the programmer at compile time with compile time exception handling. Maybe the programming language itself was to blame? (I believe otherwise, but seeing as we are trying to spread blame away from the users and programmers right now) 3 tools to code with in the windows realm are not as developed/functional as they are in other envs Visual Studio despite anyones opinion of MS software is actually a very good development environment. Many of the features are in constant use to achieve true RAD. 4 M$ does not properly provide developers with clued information with which to do their job. I have always found MSDN to be plenty complete enough, if sometimes dauntingly huge. I hope that you did not derive this statement as a product of the article posted. The flaw in the system was known and published but the users simply did not take any action. It would be easy to solve this problem. It would be easier yet to automatically reboot the systems on the regular basis (although this would not provide proper warning across the system I suspect, and ATC dropping unannounced is not the best of ideas). Why was none of this done? Not because of poor OS and library documentation. Was that a knowledgeable bash at MS or was that just another random spasm? The simple truth is that there are many people who contribute to this list and others who can vouch for the fact that there exists MS Windows servers which can stay up plenty longer than 50 days. There exist many applications (finely timed ones too) which can run on said systems, again for more than 50 days. If this is the case, and the software itself has some kind of flaw which causes otherwise, is the OS to blame or the programmer of the foreign software? Maybe next time a software development team is chosen to write a mission critical application they should actually get some coders with experience in mission critical application development. =) ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Windoze almost managed to 200x repeat 9/11
Definitely some interesting theories Ron. 1 the code was better done under the original OS, unix While possible, nothing actually points at this as being the case. Anyway, I would be curious as to the functionality of the system when it was first launched on UNIX versus the end-result. Put this on Windows and run it 10 years and then port to UNIX or *nix and there will almost certainly be screwups there as well. In fact, I would be pretty confident. I have dealt with poor ports to and from Windows and *nix. I have even dealt with bad ports from Mainframes to UNIX where the whole time the Mainframe people were saying the same types of things about UNIX that you like to say about Windows. Being a good coder for one OS doesn't make you one for all Oses when dealing with system level components and interfaces. 2 considering how often you seems to run into this same issue with other coders in the windows realm, windows coders tend to be especially lazy/clueless as compared to coders in other OS' I would expect the issue is the same as always. Sheer volume. There are good and bad coders period. Microsoft has surely drawn more poor coders than any other OS with its pushing of the RAD/simple coding environment such as VB. Additionally the Windows environment as a whole has more inexperienced users and admins and people likely to try and code. There are also many good ones as well, they are just well buried in the poor ones. 3 tools to code with in the windows realm are not as 3 developed/functional as they are in other envs I would say this opinion is uninformed. 4 M$ does not properly provide developers with clued information with which to do their jobs This is another opinion which I would call rather uninformed. Even if there was poor function documentation, if you have a function, any function returning a constantly increasing counter you know, as a skilled programmer, that eventually it has to do something other than increase. If the value is signed the sign bit will flip or if it is unsigned it will roll to 0. How can a good programmer think any other thing? The compiler could have inserted exception handling code but at best that is simply going to bounce the program out of a normal running state. That is a compiler thing though, not an OS thing. I do hope you aren't trying to tell me that UNIX can magically and infinitely maintain a counter on a variable with a fixed bit size. I try to consider you to be a bit more intelligent than that. To put it in anotehr way, if you have a set of tires on a car that are rated for 75 MPH (say off road truck tires) and some person goes 90 and the tires fly apart or the vehicle flips or both, is the issue the driver, the vehicle manufacturer, the tire manufacturer, or the tree that produced the rubber for the tire? This is the same sort of case. You have it in your mind ahead of time who you want to be at fault because you have a bug up your bum about it and work to prove that stance. Poor coding is a result of poor coders. I have seen amazingly bad code on all OS/RTS platforms I have worked on from RSTS to BSD to Linux to Windows to DOS to VMS. I have also seen some amazingly good stuff on the same platforms. Someone who doesn't understand basic data types and how to handle their limits is going to do a shitty job on all of the platforms. Is the ratio of good admins to bad admins better in UNIX versus Windows? Absolutely. Is the ratio of good programmers to bad programmers better in UNIX versus Windows? Most certainly. Does this mean all Windows admins are bad admins, obviously not. Does this mean all Windows programmers are bad programmers, obviously not. I specifically say UNIX versus *nix because I think *nix is one or more steps closer to Windows in this discussion and getting closer as its popularity grows with Windows users. Switching to *nix doesn't make the admins or coders switching (or just using in tandem) any better simply because they switched. -Original Message- From: Ron DuFresne [mailto:[EMAIL PROTECTED] Sent: Friday, September 24, 2004 11:25 PM To: joe Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [Full-Disclosure] Windoze almost managed to 200x repeat 9/11 On Fri, 24 Sep 2004, joe wrote: Again, there are valid uses of GetTickCount and there are safe ways of doing so. If there is concern, I do recommend testing functionality associated with each of the DLLs. You might find a bug you can report for kudos. On the incident, I would guess the vendor never had a clue it would do that. That function can't return more than 49.7 days without breaking every app that currently uses it. MS can not do that. That is why there is another function to get the info with a different datatype. See my other posts. What seems to read clearly from your replies to this thread is that either; 1 the code was better done under the original OS, unix 2 considering how often you seems to run into this
RE: [Full-Disclosure] MS04-028 Jpeg EXPLOIT with Reverse and Bind shell ...
I just compiled this and it works well.. But It screwed up the graphic..but I think it supposed to do that right ? I got a connect back shell when I made the poisonjpeg !! Anyone else tried this ... I can see this ones gaana be fun... raz ElviS .de wrote: the last step before the worm http://www.k-otik.com/exploits/09252004.JpegOfDeath.c.php Are securepoint giving away consultancy jobs for the first working implementation this time ? ;) ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Re: Computer security and Sex
snip Joe had previously RTFM, and knew just what to do /snip took me a secound, but thats my #1 i don't get everything but good work! m i s i u ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Windoze almost managed to 200x repeat 9/11
Joe dude, how much u are getting from M$ a month to hang around this list ? Zero ? Nowaysend em a letter now dude. And please don't serve me, 'just being objective crap', you HAVE to be interested to defend it that well., if not, well, you may be missing on something... joe wrote: Definitely some interesting theories Ron. 1 the code was better done under the original OS, unix While possible, nothing actually points at this as being the case. Anyway, I would be curious as to the functionality of the system when it was first launched on UNIX versus the end-result. Put this on Windows and run it 10 years and then port to UNIX or *nix and there will almost certainly be screwups there as well. In fact, I would be pretty confident. I have dealt with poor ports to and from Windows and *nix. I have even dealt with bad ports from Mainframes to UNIX where the whole time the Mainframe people were saying the same types of things about UNIX that you like to say about Windows. Being a good coder for one OS doesn't make you one for all Oses when dealing with system level components and interfaces. 2 considering how often you seems to run into this same issue with other coders in the windows realm, windows coders tend to be especially lazy/clueless as compared to coders in other OS' I would expect the issue is the same as always. Sheer volume. There are good and bad coders period. Microsoft has surely drawn more poor coders than any other OS with its pushing of the RAD/simple coding environment such as VB. Additionally the Windows environment as a whole has more inexperienced users and admins and people likely to try and code. There are also many good ones as well, they are just well buried in the poor ones. 3 tools to code with in the windows realm are not as 3 developed/functional as they are in other envs I would say this opinion is uninformed. 4 M$ does not properly provide developers with clued information with which to do their jobs This is another opinion which I would call rather uninformed. Even if there was poor function documentation, if you have a function, any function returning a constantly increasing counter you know, as a skilled programmer, that eventually it has to do something other than increase. If the value is signed the sign bit will flip or if it is unsigned it will roll to 0. How can a good programmer think any other thing? The compiler could have inserted exception handling code but at best that is simply going to bounce the program out of a normal running state. That is a compiler thing though, not an OS thing. I do hope you aren't trying to tell me that UNIX can magically and infinitely maintain a counter on a variable with a fixed bit size. I try to consider you to be a bit more intelligent than that. To put it in anotehr way, if you have a set of tires on a car that are rated for 75 MPH (say off road truck tires) and some person goes 90 and the tires fly apart or the vehicle flips or both, is the issue the driver, the vehicle manufacturer, the tire manufacturer, or the tree that produced the rubber for the tire? This is the same sort of case. You have it in your mind ahead of time who you want to be at fault because you have a bug up your bum about it and work to prove that stance. Poor coding is a result of poor coders. I have seen amazingly bad code on all OS/RTS platforms I have worked on from RSTS to BSD to Linux to Windows to DOS to VMS. I have also seen some amazingly good stuff on the same platforms. Someone who doesn't understand basic data types and how to handle their limits is going to do a shitty job on all of the platforms. Is the ratio of good admins to bad admins better in UNIX versus Windows? Absolutely. Is the ratio of good programmers to bad programmers better in UNIX versus Windows? Most certainly. Does this mean all Windows admins are bad admins, obviously not. Does this mean all Windows programmers are bad programmers, obviously not. I specifically say UNIX versus *nix because I think *nix is one or more steps closer to Windows in this discussion and getting closer as its popularity grows with Windows users. Switching to *nix doesn't make the admins or coders switching (or just using in tandem) any better simply because they switched. -Original Message- From: Ron DuFresne [mailto:[EMAIL PROTECTED] Sent: Friday, September 24, 2004 11:25 PM To: joe Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [Full-Disclosure] Windoze almost managed to 200x repeat 9/11 On Fri, 24 Sep 2004, joe wrote: Again, there are valid uses of GetTickCount and there are safe ways of doing so. If there is concern, I do recommend testing functionality associated with each of the DLLs. You might find a bug you can report for kudos. On the incident, I would guess the vendor never had a clue it would do that. That function can't return more than 49.7 days without breaking every app that currently uses it. MS can
Re: [Full-Disclosure] MS04-028 Jpeg EXPLOIT with Reverse and Bind shell ...
On Saturday 25 September 2004 16:59, raza wrote: I just compiled this and it works well.. But It screwed up the graphic..but I think it supposed to do that right ? I got a connect back shell when I made the poisonjpeg !! Anyone else tried this ... yes and it works very well. I can see this ones gaana be fun... We'll have a worm within days. .Filb ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] MS04-028 Jpeg EXPLOIT with Reverse and Bind shell ...
umm, no all this has thats different is correct headers for bind or remote shell option. and ability to set ports and return ip in the code, instead of needing to use your own shellcode ( or metasploits ) note: there is no new exploit code or vector --- / snip /- new. char header1[] = \xFF\xD8\xFF\xE0\x00\x10\x4A\x46\x49\x46\x00\x01\x02\x00\x00\x64 \x00\x64\x00\x00\xFF\xEC\x00\x11\x44\x75\x63\x6B\x79\x00\x01\x00 \x04\x00\x00\x00\x0A\x00\x00\xFF\xEE\x00\x0E\x41\x64\x6F\x62\x65 \x00\x64\xC0\x00\x00\x00\x01\xFF\xFE\x00\x01\x00\x14\x10\x10\x19 \x12\x19\x27\x17\x17\x27\x32\xEB\x0F\x26\x32\xDC\xB1\xE7\x70\x26 \x2E\x3E\x35\x35\x35\x35\x35\x3E; --- / snip /- old. --- / snip /- char header1[]= \xFF\xD8\xFF\xE0\x00\x10\x4A\x46\x49\x46\x00\x01\x02\x00\x00\x64 \x00\x64\x00\x00\xFF\xEC\x00\x11\x44\x75\x63\x6B\x79\x00\x01\x00 \x04\x00\x00\x00\x0A\x00\x00\xFF\xEE\x00\x0E\x41\x64\x6F\x62\x65 \x00\x64\xC0\x00\x00\x00\x01\xFF\xFE\x00\x01\x00\x14\x10\x10\x19 \x12\x19\x27\x17\x17\x27\x32\xEB\x0F\x26\x32\xDC\xB1\xE7\x70\x26 \x2E\x3E\x35\x35\x35\x35\x35\x3E; --- / snip /- take your media hype and die kthnx, m.wood the last step before the worm http://www.k-otik.com/exploits/09252004.JpegOfDeath.c.php ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Windoze almost managed to 200x repeat 9/11
On Sat, 25 Sep 2004 10:35:34 -0400, joe [EMAIL PROTECTED] wrote: Even if there was poor function documentation, if you have a function, any function returning a constantly increasing counter you know, as a skilled programmer, that eventually it has to do something other than increase. In this case, the function is very well documented. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/gettickcount.asp From the documentation, The elapsed time is stored as a DWORD value. Therefore, the time will wrap around to zero if the system is run continuously for 49.7 days. If you need a higher resolution timer, use a multimedia timer or a high-resolution timer. Even without that documentation, common sense would tell you that it will only count for up to 49.7 days. The function returns a DWORD. The largest number that can be held by a DWORD is or 4,294,967,295 decimal. Since you know those are milliseconds, divide by 1000 to get seconds, then by 60 for minutes, 60 again for hours, and 24 for days and you get just over 49.7 days (or just go to http://www.google.com/search?hl=enlr=ie=UTF-8q=4294967295+milliseconds+in+days). You can't blame the OS. The developers of the application used an obsolete API call that was probably only left in for older applications. Sure, there have been times when Microsoft programmers have screwed up, but this is not one of them. Microsoft clearly documented it as a DWORD with a finite value. I think the worst thing about this is that the FAA and the developers of the app knew about the problem for quite some time, knew what the problem was, and, rather than fix the code, they just rebooted the system to work around it and ignored the main problem. -- Troy ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Windoze almost managed to 200x repeat 9/11
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Troy Sent: Saturday, September 25, 2004 12:41 PM To: [EMAIL PROTECTED] Subject: Re: [Full-Disclosure] Windoze almost managed to 200x repeat 9/11 I think the worst thing about this is that the FAA and the developers of the app knew about the problem for quite some time, knew what the problem was, and, rather than fix the code, they just rebooted the system to work around it and ignored the main problem. -- Troy This type of workaround is typical in mission critical code where the cost of recertification exceeds the cost of the workarounds). It is not enough to show that the (corrected) program logic solves a known problem. The (unknown) side effects of adding code (and moving code/data in memory, which may expose another bug/feature) means that the entire system must be recertified to allow a change to move to production. Recertification for large systems can easily run into the millions (when you look at fully encumbered costs). The real issue was not that there was a known problem (all large systems have bugs/features), nor that a choice was made to apply a workaround rather than correct the root cause. It was that the workaround for the problem did not deal with the failure mode of the person (apparently) failing to do his/her job of restarting the system. There should have been some checks to insure that the workaround was performed. I'll bet that the FAA is now instituting such checks. But, of course, hindsight is 20/20. Gary ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Yahoo! Store Security Advisory
On Sat, 25 Sep 2004 22:11:27 +0100, xploitable [EMAIL PROTECTED] wrote: On Fri, 24 Sep 2004 00:44:05 -0400, Stuart Moore [EMAIL PROTECTED] wrote: Yahoo! Store Security Advisory Advisory: http://securitytracker.com/id?1011403 Date: September 23, 2004 Vendor:Yahoo! Product: Yahoo! Store Status:Fixed by the vendor; Coordinated release Credit:Ben Efros [EMAIL PROTECTED] http://www.citiprice.com/ Description: Ben Efros reported the following vulnerability in the Yahoo! Store shopping cart to SecurityTracker [EMAIL PROTECTED] on August 15, 2004. A remote user can effectively alter the price of merchandise being placed into their shopping cart. A remote user can submit modified HTML to the affected commerce site with an unauthorized item option or with a valid option that has been price-modified. The system will compute the order using the price of the option, which can be a positive or negative value. If the merchant does not review the order prior to fulfillment, the item may be sold for the incorrect price. The 'options' select item lists are intended to be used to define separately priced purchasing options, such as additional accessories, different sizes, extended warranties, and express shipping. An example of a select item option is provided: SELECT NAME=Express Shipping OPTIONNo/OPTION OPTIONYes (+8.95)/OPTION /SELECT A remote user can modify the price of the select item option to an arbitrary value, even to a negative number. If an item is purchased with a negative price option selected, then the price of the order will be reduced by the negative amount selected. If a merchant does not use options, a remote user can still add an arbitrary option with an arbitrary price. Notification Timeline: August 15, 2004 - Vendor notification September 8, 2004 - Vendor fix September 8, 2004 - Merchant notification September 23, 2004 - Public advisory Solution: The vendor issued a production fix on September 8, 2004. The fix adds an Item Options Validation setting for merchants so that merchants can automatically reject unrecognized options. The default configuration for existing merchants is to reject unrecognized options. The vendor has described the new option at: http://help.yahoo.com/help/us/store/store-44.html SecurityTracker thanks Ben Efros for reporting this flaw and Yahoo! for their response and remediation efforts. This advisory is copyright 2004 by SecurityTracker (SecurityGlobal.net LLC). Permission is granted to redistribute this advisory in electronic form in its entirety and without modification. http://securitytracker.com/ [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html snip Status:Fixed by the vendor; Coordinated release /snip Yahoo! Team are ignorant security professionals who work 9 to 5 and don't actually have a clue about -real- security issues at Yahoo! Yahoo! Security team deserve no respect from the security community, they treat people who disclose major vulnerabilities like shit. Fuck Yahoo! Security Team and Scott Renfro for not fixing his e-mail headers so it doesn't disclose his Corporate ID.. I sent the vulnerability to Yahoo! months and months ago, but even though they sign each e-mail with Yahoo! Security Contact, they don't seem to mind if the headers show the -real- sender. Yahoo! Security Team in Sunnyvale seem to have changed the header [EMAIL PROTECTED] to [EMAIL PROTECTED], but Scott Renfro from the Dallas Incident Response Address seems to leave his mail client with his corp ID showing. Lets not forget how stats.yahoo.com got hacked because of silly employees leaving ID's lying about. Oh I forgot the media never got to find out about that hack .. They have now. Bye, xploitable -- http://www.geocities.com/n3td3v - Yahoo! Security Forum *Online*. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] Yahoo! Store Security Advisory
On Sat, 25 Sep 2004 17:38:29 -0400, Stuart Moore [EMAIL PROTECTED] wrote: xploitable, Yeah, it did take us some effort to get in touch with them. And they did not want to say thanks for reporting it. Oh well. I think having such a basic flaw in a commerce system speaks loudly about the nature of security at Yahoo. Stuart They don't know how to have a human discussion about serious flaws you send them. They are so self centred They make me want to act like a script kiddie and be malicious to the Yahoo! network, but of course I know thats a irresponsible thing to do. Peace. -- http://www.geocities.com/n3td3v - Yahoo! Security Forum *Online*. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Windoze almost managed to 200x repeat 9/11
[SNIP] 2 considering how often you seems to run into this same issue with other coders in the windows realm, windows coders tend to be especially lazy/clueless as compared to coders in other OS' This is possibly true, but you may well find that this correlated back to the whole usage of WYSIWYG OS and design tools and the general non tech nature of the average windows user. It is also possible that the IDE in use can also contribute to reduced reading of proper API documents which leads to errors of this sort due to their ease of use and a lack of attention to detail on the programmers side. Poor quality assurance practices are what leave this kind of error unnoticed (least we not forget however that this error WAS noticed and documented). And yet relied upon a reboot of the system to correct, large gamble here, it's not that uncommon for a system to *not* recover from a reboot, and murphy's law is seriously implied, even of the systems were redundant. Yet, and I must admit, my post in this thread was kind of a ringer, damned if you do, damned if you don't. But, I'm surprised at how quickly folks are latching into my assertion that windows coders might not be up to the task, especially in mission critical and life on the line systems. the implications are strong here that systems either mission critical or where lives are on the line should not be tasked to an env whence the folks 'behind the sceens' are likely to not be up to the task. and this goes hand in hand with the advice I have been giving to my present employer on web hosting; do not put your most visible and critial sites on an OS not only prone to issues due to it's imaturity, but, also one so easily targetted for exploit that your most visible and high profile sites are going to be sploited and defaced...the flaw in most these cases is that mgt only understand point and click and ease, and has troubles wrapping the brainpower upon the concept of durable resistance and experience being a critical factor. I think of all the asertions I made after reading this thread, this was the most damaging one for annyone to agree to a level of correctness on... Thanks, Ron DuFresne -- ~~ Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation. -- Johnny Hart ***testing, only testing, and damn good at it too!*** OK, so you're a Ph.D. Just don't touch anything. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Windoze almost managed to 200x repeat 9/11
On Sat, 25 Sep 2004, joe wrote: Definitely some interesting theories Ron. 1 the code was better done under the original OS, unix While possible, nothing actually points at this as being the case. Well, nothing was mentioned about a system needing a reboot ever 49 days on the old unix env... [SNIP] 2 considering how often you seems to run into this same issue with other coders in the windows realm, windows coders tend to be especially lazy/clueless as compared to coders in other OS' I would expect the issue is the same as always. Sheer volume. There are good and bad coders period. Microsoft has surely drawn more poor coders than any other OS with its pushing of the RAD/simple coding environment such as VB. Additionally the Windows environment as a whole has more inexperienced users and admins and people likely to try and code. There are also many good ones as well, they are just well buried in the poor ones. See my reply to James Tucker, who beat you to the punch on my MUA in responding in like manner on this same point, it applies to your response as well. I have a feeling that many M$ admins and coders are going to take a serious offence to James and you so readily agreeing this might be a core issue with the system at hand. Thanks, Ron DuFresne -- ~~ Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation. -- Johnny Hart ***testing, only testing, and damn good at it too!*** OK, so you're a Ph.D. Just don't touch anything. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Yahoo! Store Security Advisory
They don't know how to have a human discussion about serious flaws you send them. They are so self centred They make me want to act like a script kiddie and be malicious to the Yahoo! network, but of course I know thats a irresponsible thing to do. This is precisely why I say 'fuck it' and believe that if/when you find something, publish it immediately. Don't bother giving notice to the vendors, whoever it is. Unless of course they're good people or you have an agreement. My personal rule is 'respect by default': everyone gets the benefit of the doubt (except Microsoft) but as soon as they step over the line, they've probably blown it forever. This includes them taking their sweet time getting back, being rude, nothing but form letters, etc. I'm deadly serious; sometimes (i.e. too frequently) people need a fierce bitch-smacking to get their shit in order. Maybe when they finally realize and appreciate that people are going out of their way to look for issues in their product(s) or service(s) they'll smarten up. (Yeah right, but we can dream). I have a few ideas about things that could be done to drive the point home more effectively, and it basically centres around hitting them where it hurts. Where's that? The wallet! So: 1. Publish the vuln/sploit/hole/whatever to media friendly lists 2. Make sure the info makes it to their competitors 3. Make sure the info makes it to their investors 4. Make sure the info makes it to their business partners 5. Make sure the info gets to their most relevant user communities When it comes to investors, business partners, competitors, etc. it would really help to do your research and know who to contact inside the organization. Don't just send it to some email posted on their website (though do that too) call up the switchboard and socially engineer your way into finding out who the people who make stuff happen is. All of this would be helped by well written, intelligent documentation of the issues at hand. Don't speak like a lame scr1p7 |1dd13 or stuff like that. Make it as easy as possible for people who are receiving the information to verify that is (a) true and (b) exploit the vulnerability. Include POC code. Write it so that even people who use Macs and WindowsXP can figure out how to wreak havoc with it, ie. give them a binary. Perhaps I'll call this 'Ultimate Disclosure'? Kick them in the nuts, and keep kicking, until they learn to run when they see you coming. Regards, Byron ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Windoze almost managed to 200x repeat 9/11
joe wrote: Other articles state that as which replaced the original servers with off-the-shelf Dell hardware running Microsoft Windows 2000 Advanced Server Also there are other mentions of Windows Servers replacing UNIX servers. Don't think I have ever met someone who would be willing to call Win9x a server. neither would i call 'server' anything with a graphic interface. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
