Slashdot Mirror

Microsoft put little more than a CDDB lookup into their player.

Err. Mind explaining what kind of use a CDDB lookup might have for DVDs?

And as far as the "Keeping your eggs in one basket" thing, that's been done, from the inside yet.

After I bought it and plugged it in, and I sat down and read up on security, and I was simply shocked at how the Linksys equipment have completely zero security.

The most you can do to protect yourself is:

1) disable SSID broadcasts
2) filter based on MAC addresses
3) use 128 bit WEP to obfuscate your data to only the casual

Of course, WEP can be broken by any hacker worth his-or-her salt, and filtering based on MAC addresses doesn't work because you can spoof MAC addresses. There is zero security from a determined hacker.

The Linksys APs also have a severe security issue where anyone can get the ssid through a simple udp broadcast, meaning they don't even need a valid IP address. Once they get your SSID, it makes it way easier to connect to the AP.

From what I've heard, Linksys even isn't doing anything about it.

It really seems as though 802.11X is going to only find a place at home where consumers care more about getting rid of wires than about security. There is no valid reason for a business or governments, where their information is worth much much more, to be using such a security-free mechanism.

I'm okay because I needed the wireless stuff for my gf's computer, and all she does is surf the web. I put in place a FreeBSD firewall just in case, so I'm not too worried about my neighbors or wardrivers getting connected. But for those people that don't care about security, this is probably the way that untraceable hacking in the 21st is going to go through - via some idiot that left his 802.11b connection open to hackers that live across the street, or just happened to pull by in their car to try and hack into some military site, etc.

As to spyware, it's not exactly like any software house has to be complicit to get it on your system if you use the Internet and download programs. Read here for details.

This is what makes the Microsoft certificate chain vulnerability and SSLSniff particularly dangerous.

You're assuming that your browser is immune to man in the middle attacks. It may not be.

It's nice to see that the computing industry as a whole is following Micro$oft's example and taking security "so seriously".

Linked to here: Gov't Rests Case Against Russian SW Co.

Can't comment, gotta go put out a fire...

You could start by subscribing to the forensics mailing list over at securityfocus.com. The honeypots list is also of interest.

Both lists have a fairly good signal-to-noise ratio, and there is a lot of good info to be had.

If nothing else, it's certainly a good place to ask that exact question.

You can sign up here.

No, the phone itself does not have a MAC address, in fact, it doesn't even have an IP stack. That is all managed upstream in the providers network. In GPRS that is done by devices called SGSNs and GGSNs, though I'm not sure about how EDGE and UMTS will handle it. Although, it does act like an "always on" connection. Interesting article here about how T-Mobile is dealing with the issue (or not).

As for figuring out where you are, providers have always known where you are to some extent based on the which tower you are registered to. They must store this to bill you effectively. The only difference with the new location based services (on the phone via GPS or on the network via triangulation) is how acurate they are and who this information gets shared with. It may be with your local 911, or with a friend.

depends - what version are you running now?

there is an adk (additional decryption key) insertion vulnerability in version 6.5.3 and earlier

"Intrusion Detection" has over 50 systems. I use Claymore (utterly simply, has saved my arse completely on one occasion).

Tripwire has mindshare - not much else it seems.

Here's yet another one published, and here's David Ahmad's response in light of these recenty discussions.

What I don't understand in this whole mess: when I hear "execute arbitrary code", I know something's horribly broken. Why is it worse if someone exemplifies "arbitray code" with "format a: /autotest" (in the ZDnet forum, reposted to BugTraq here) instead of "winmine" (as in Sandblad's original advisory)? The important bit is "arbitrary code", no?

Here's yet another one published, and here's David Ahmad's response in light of these recenty discussions.

What I don't understand in this whole mess: when I hear "execute arbitrary code", I know something's horribly broken. Why is it worse if someone exemplifies "arbitray code" with "format a: /autotest" (in the ZDnet forum, reposted to BugTraq here) instead of "winmine" (as in Sandblad's original advisory)? The important bit is "arbitrary code", no?

Here's yet another one published, and here's David Ahmad's response in light of these recenty discussions.

What I don't understand in this whole mess: when I hear "execute arbitrary code", I know something's horribly broken. Why is it worse if someone exemplifies "arbitray code" with "format a: /autotest" (in the ZDnet forum, reposted to BugTraq here) instead of "winmine" (as in Sandblad's original advisory)? The important bit is "arbitrary code", no?

Here's yet another one published, and here's David Ahmad's response in light of these recenty discussions.

What I don't understand in this whole mess: when I hear "execute arbitrary code", I know something's horribly broken. Why is it worse if someone exemplifies "arbitray code" with "format a: /autotest" (in the ZDnet forum, reposted to BugTraq here) instead of "winmine" (as in Sandblad's original advisory)? The important bit is "arbitrary code", no?

The point is that even full disclosure only requires 'proof of concept' malicious code. There is no benefit on going the last step and widely circulating examples of code that actually f***s your hard disk.

The page with the code example linked from the Wired article is completely benign; the worst it does is write a text file to your C: drive. Someone would have to know more about IE tricks in order to turn it into something malicious.

After reading the proof-of-concept script at http://online.securityfocus.com/archive/1/298748, I now know at least to avoid blind links.

Also, I've come up with this possible solution:

In IE, bring the potentially malicious page to the front, then press Ctrl-O to get the Open prompt. Enter this:

javascript:void(location.replace=null)

then click OK. Now anytime that a javascript on that page tries to do a location.replace command will now instead issue a null command (no command at all). (Assuming the script hasn't already been activated, under an onLoad event or something)

This works with annoying exit pop-up ads too:
javascript:void(window.onunload=null);

You can do this with all sorts of javascript commands that get abused. Find some offensive pages, look at their source, and disable the commands you see used often. (onunload is probably the worst and most often used).

Major inspiration from this cnet builder page.

If you read Sandblad's actual BugTraq posting you will see that he had notified Microsoft more than a month before posting the details of the exploit. Quoting:

Microsoft was initially contacted 2002-10-04. After several mail exchanges, their final response were that the technique used to run programs with parameters from the "Local computer zone" was no security vulnerability. A fix should instead be applied for all possibilities for content in the "Internet zone" to access the "Local computer zone".

How much time does a company have to actually fix a problem this serious? When somebody takes the trouble to notify a company about a defect, they've already demonstrated helpfulness and responsibility. It would make sense for the company to take that helpful, responsible person into the loop, and at least update them periodically about what is being done about the problem. That would give a helpful person like Sandblad a basis for continuing to wait. In this case Microsoft gave no indication that they were doing anything about the problem or intended to do anything about it. Continuing to sit on the information certainly wouldn't give them any further incentive. Sandblad reported this problem, got a thanks-but-no-thanks, then after a month of no news went over their heads to the public. I would say he handled it very responsibly.

In germany Heise.de even published an exploit:

C't Browsercheck

You can test your IE and report the results to your boss.

See also:

Sandblad at Securityfocus

Parent's comments are stolen from SecurityFocus: Computer Break-Ins: Your Right to Know

This is taken right from SecurityFocus: Computer Break-Ins: Your Right to Know

Stolen from SecurityFocus: Computer Break-Ins: Your Right to Know

irssi
fragroute, dsniff, fragrouter
BitchX

This message says Recently there have been a spat of well publicized attacks against what I would consider to be the backbone of the open source movement - it's source code distribution system. Hackers have been penetrating people who download, say, OpenSSH and then compile it to use on their systems by trojaning OpenSSH itself. This strikes at the very HEART of Open Source by making the act of installing the software a weakness. Because Open Source has no one distribution point, there are many places for someone to verify if they want to install software securely. Because there are no vendors, the sites people download software from are usually not provided with a dedicated security staff.

This is serious, guys and gals. Use the source, Luke - but what if I can't trust the source any more? Open Source has to find a method to get around this problem; see this post.

Not exactly. The question was more complicated than "how do I make sure no one can decrypt a datastream on my wireless network?" It was how to make sure no unauthorized user is connected. This is much more difficult.

A similar question spawned a thread on security focus' vuln-dev mailing list a couple of weeks ago. Good read.

yep. definitely a much safer, and more secure choice.

Just a few points here: - I don't think there's a conspiracy here. J is moving and that's it. ICANN does not have to go "stop the presses! J ROOT SERVER is moving". They just have to release the new hints file. There's no need to panic, as someone posted before. - The 13 root servers were attacked, A (hosted by Verisign at undisclosed location ) survived the attack and J didn't. Why not move J to a safer place? - Improving the security of the root servers is a *good* thing, not a bad one. The root servers network is a sensitive one, and everything done there must be done very carefully, especially after the DDoS. - Go get some sleep, the root servers around the world will grant you the right to translate IP addresses :)

As a technology professional and, based on someone who I think would agree with most of your political stances (that is, I'm want to be nice about this), please have your website amended by a qualified professional. The form used to send this message has a couple of problems that really ought to be addressed:

• There is no good reason for a web form such as this to force visitors to use a particular kind of browser software to access it. In spite of the recent court decision t hat would suggest otherwise, Microsoft has been tried & convicted as an abusive monopolist, and if visitors take the initiative to use alternative software they should be applauded, not excluded. Keeping out users based on their commercial choices seems very anti-democratic to me.

• Skimming the HTML source of this form, I note that it includes hidden fields for "mailto" and "url". That is a very bad sign, because there are well known security problems with certain freely available web form processing programs that are widely used on the web today, and one of the signatures of these dangerously broken programs is that they allow users to set fields like this. The reason that is a problem is that it allows a malicious user to send false data to your program, and by so doing hijack it & do anything from send out spam mail to carry out certain forms of identify theft or defamation of character. Rather than allowing the user to set this data in the web form, you would be much better off by moving that data into your server script instead. Your tech staff will hopefully know how to do this; if not I would be happy to answer any questions. To give a couple of reference URLs, I offer:
• http://www.securityfocus.com/corporate/research/to p10attacks_q1_2002.shtml
• http://nms-cgi.sourceforge.net/faq_nms.html#But%20 there%20are%20perfectly%20good%20programs%20alread y%20out%20there%2C%20why%20bother%3F
• http://www.scriptarchive.com/nms.html
• http://www.google.com/search?q=formmail+security+c gi

Thank you for your attention, and for God's sake keep voting against Bush's war against Iraq. I'm sure history will prove that you were right to oppose this. Your speech against it, at http://www.house.gov/tubbsjones/pr021009.htm, was wonderful. Thank you.

Hey, it got written up, it might as well get posted somewhere. Maybe her staff will decide to start reading Slashdot today...

Here is a mailing list archive or yet another redundant reference of this problem. It's almost a year old. Come on slashdotters, don't get sloppy in the deluge huh?

The vulnerabilities listed are all already fixed in mozilla 1.01 and 1.1, except for the potential privacy violation in onUnload (bugzilla). That one's hardly terrible - it's possible to add javascript to your website so that you can tell which url the user went to when he leaves your site. Pretty minor given that a) it just tells the "attacker" which of his links you clicked and b) a lot of sites already achieve the same effect using links to redirect scripts instead of direct links.

This whole thing is really overblown. The issue the register picks on as the most important - the https-http-https redirect warning thing - is actually the least important. They talk about the importance of HTTPS for ecommerce but they don't seem to understand what the real security issues here (Oh my god, a malicious website can confuse me about whether my connection to it is encrypted! Doom! We're all doomed!).

Most of those bugtraq/securityfocus listings are from a list of fixed security bugs that the mozilla people fixed and listed in bugzilla that were posted to bugtraq. It doesn't help anyone improve security if your reward for being open is a scaremongering article that says your product is "riddled with security holes". It's an easy way for The Register to get hits knocking mozilla with most of their work already done for them - by the mozilla developers.

The vulnerabilities listed are all already fixed in mozilla 1.01 and 1.1, except for the potential privacy violation in onUnload (bugzilla). That one's hardly terrible - it's possible to add javascript to your website so that you can tell which url the user went to when he leaves your site. Pretty minor given that a) it just tells the "attacker" which of his links you clicked and b) a lot of sites already achieve the same effect using links to redirect scripts instead of direct links.

This whole thing is really overblown. The issue the register picks on as the most important - the https-http-https redirect warning thing - is actually the least important. They talk about the importance of HTTPS for ecommerce but they don't seem to understand what the real security issues here (Oh my god, a malicious website can confuse me about whether my connection to it is encrypted! Doom! We're all doomed!).

Most of those bugtraq/securityfocus listings are from a list of fixed security bugs that the mozilla people fixed and listed in bugzilla that were posted to bugtraq. It doesn't help anyone improve security if your reward for being open is a scaremongering article that says your product is "riddled with security holes". It's an easy way for The Register to get hits knocking mozilla with most of their work already done for them - by the mozilla developers.

A disclaimer first: I haven't tried to do this on MacOS X, but just did the same for Linux; you can do it on any unix that supports PAM for authentication.

It is certainly possible, however I wouldn't call this integration a "seemless" one (I didn't use samba for that).

You can extend AD schema to support unix by using AD4Unix package.
After that you need to install nss_ldap and pam_ldap. A good starting point on how to configure these two can be found at Security Focus. You may want to use Kerberos for authentication, as pam_ldap transmits username and password over the network (although with SSL support this data will be encrypted).

Hope this helps,
AC

just use:

<a href="http://online.securityfocus.com/archive/82/1 73944">http://online.securityfocus.com/archive/82/ 173944</a>

Remember to set style to "HTML Formatted" and but a <br> tag at the end of each line.

just use:

<a href="http://online.securityfocus.com/archive/82/1 73944">http://online.securityfocus.com/archive/82/ 173944</a>

Remember to set style to "HTML Formatted" and but a <br> tag at the end of each line.

See How to get certified security for Win2k, by Microsoft

Idiot, it's been on bugtraq for days now... http://online.securityfocus.com/archive/1/296819.. .

and the netbsd security advisory was a day earlier then that, even...

Sure, do an AXFR (A-record transfer) with DiG on a root server. Of course, you have to be a priviledged user--AXFR requires full-duplex TCP instead of an ordinary UDP connection, so unfortunately *.root-servers.net and *.gtld-servers.net don't allow transfers. Yet some of the international country-code TLDs (ccTLDs) allow AXFR transfers; if you wanna host .AG or whatever just do a dig axfr and you're good to go.

Umm, nope, I would challenge that point. VBS and other scripting stuff is turned off by default. I've never heard of a buffer overflow exploit in OL, but if you have an example somewhere I'd love to read about it. (in other words, I'm not claiming it doesn't exist.)

Well, take for instance the vcard Buffer Overflow vulnerability that was unique to Outlook 2000.

The long GMT date field bug bug caused a buffer overflow which allowed running arbitrary code in all versions of Outlook, as well as in some versions of Outlook Express.

Seeing as Outlook uses Internet Explorer to display HTML content, just like Outlook Express does, it inherits IE's flaws as well, as was demonstrated in the Buffer Overrun in HTML Directive flaw.

As for VB scripting being turned off by default now, that may be the case with Outlook XP (2002) or 2000 with all security patches applied, but I can assure that wasn't the case back in 2001 when the Anna Kournikova Worm and other similar exploits scourged through the Outlook community.

Umm, nope, I would challenge that point. VBS and other scripting stuff is turned off by default. I've never heard of a buffer overflow exploit in OL, but if you have an example somewhere I'd love to read about it. (in other words, I'm not claiming it doesn't exist.)

Well, take for instance the vcard Buffer Overflow vulnerability that was unique to Outlook 2000.

The long GMT date field bug bug caused a buffer overflow which allowed running arbitrary code in all versions of Outlook, as well as in some versions of Outlook Express.

Seeing as Outlook uses Internet Explorer to display HTML content, just like Outlook Express does, it inherits IE's flaws as well, as was demonstrated in the Buffer Overrun in HTML Directive flaw.

As for VB scripting being turned off by default now, that may be the case with Outlook XP (2002) or 2000 with all security patches applied, but I can assure that wasn't the case back in 2001 when the Anna Kournikova Worm and other similar exploits scourged through the Outlook community.

Please see this post and other related posts in this mailing list for details about what exactly is being observed.

How many bugs for Windows have been swept under the rug?

How many bugs for Windows have been swept under the rug?

Freeh needs to find a whipping boy for the failures of correlating the various peices intelligence datum, which occurred on his watch. Restricting legal access to crypto will only assist in the illicit observation of constitutionally protected speech by private individuals, and destroy what little competitive advantage is enjoyed by U.S. software industries over their counterparts in Israel and India.

The algorithms and the source will not go "back in the can."

Louis Freeh is responsible, in a large part, for the biggest intelligence failure in modern recollection. None of the failure in this effort was for lack of access to encrypted communications, but from standard failures of organization and communications within the concerned agencies.

The Heritage Foundation - not normally critical of the FBI's mission - has this to say:

But what if FBI intelligence fails to collect, analyze and share this information? This could happen, the commission found, because "the guidelines under which FBI agents operate ... are badly written and confusing. These are guidelines that set out the terms under which the FBI can open a preliminary inquiry against somebody who may be suspected of being a terrorist. All of us read them (they run to about 42 pages) and we had a number of current and former FBI agents testify that they found them confusing."

The commission recommended that then Attorney General Janet Reno and former FBI Director Louis Freeh rewrite the guidelines into "more easily understood English."

Moreover, the FBI had no procedure for disseminating useful information for analysis within the agency or sharing it with other government agencies.

Information which was obtained, in Los Angeles, for example, but did not immediately apply to the case at hand, would simply not leave the regional office, even though it might provide important clues for another investigation, says Ambassador L. Paul Bremer, Ambassador at Large for Counterintelligence during the Reagan Administration and former Managing Director of Kissinger Associates.

Thank you! A voice of reason!

My own concern is not how GOL will be used by government (spelled out by the Privacy Act), but the potential for abuse by third parties. PKI systems are no panacea, but done right, offer assurances at least as good as what we currently have. I say bravo for my government taking this bold step.

I'm off to get mine right now - I'm keen to see what kind of certificate I'll be issued

I'm not too familiar with VMS, but Linux can and IRIX might (not support is mentioned for it) be able to use the pam_ldap/nss_ldap modules from padl.com to authenticate against Active Directory. IIRC, this requires SFU, but I could be wrong. There is a document about it in the tarball for nss_ldap.

Here's some links to Linux/AD integration from padl.com's doc section:

Active Directory and Linux

Linux-AD Integration

Active Directory and nss_ldap

/pointer

actually, OpenSSH was not the first famous case of this "trojaned configure script" practice, a few that spring to mind are:

BitchX
fragroute
and irssi

actually, OpenSSH was not the first famous case of this "trojaned configure script" practice, a few that spring to mind are:

BitchX
fragroute
and irssi

You apparently don't understand the term "security through obscurity". There have been dozens of Linux and thrid party vulnerabilities that are mentioned in passing is Slashback or delegated to one of the topic sections without making it to the front page. Off the top of my head, here's one. It doesn't matter if it's Slashcode or Apache or SSH. It's always "HEY, ANOTHER IE SECURITY HOLE!!!1!!" and 'obythewaytheresanewsshexploitkthx'

If you want to be on top of security issues, follow SecurityFocus, not Slashdot.

When one of these finally makes it to the front page, it's filled with "No, it's Symantec's fault" and "fuck Micro$oft" posts instead of recognizing the problems for what they are - plain and simple software bugs. It happens to the best of us.

Apache is far more secure than IIS and Pine is more secure than Outlook. No one is trying to deny or contest that, au contraire. But I'll be fucked if I understand why Slashdot does this sort of thing. Maybe you can explain it to us.

Funny that pretty much any "bash slashdot" post can get modded up, even if it is completely (and provably) false.

Funny that pretty much any misguided and FUD-ish post attempting to defend Slashdot from something it is clearly guilty of gets modded up.

Who sells key pairs...

Verisign.

...and how do you make the certificate show that it was verified with the intention of accting as a CA?

You don't make the certificate show that, but IE doesn't check correctly. That's the point.

I have a horrible feeling this is a +5 troll... anyone got a link to prove me wrong?

Yes, this explains in more detail.

You see that msnbc link ? seems innocent huh

when you click it though you are actually sent to msn in order to transfer your cookie from any of msn's domains which includes hotmail (any of the *.msn.com domains) in order to track you personally (if you use hotmail notice hm is actually a subdomain of msn)

so while you click on the story link of

www.msnbc.com/news/814100.asp&0dm=-23ET [msnbc.com]
you are actually sent to here

http://msid.msn.com/mps_id_sharing/redirect.asp?ww w.msnbc.com/news/create_p1.asp?URL=www.msnbc.com/n ews/814100.asp&0dm=-23ET

why ? so they can steal your hotmail/msn cookie and transfer it to the msnbc domain and track you across any of microsofts domains (hence the msid = microsoft id or guid), this gets round all browser cookie privacy limitations that browser manufacturers (including mozilla/msie/ns) implementation so websites cannot read cookies from other domains and is a blatent privacy breach,
whats happening is msid server is reading your cookie and passing it to the create_p1.asp page via a GET which then creates a new cookie with your old cookie values then finally redirects you to the story complete with transfered cookies contents, clever but not clever enough for those that spot it

of course all this cookie sharing happens in the blink of an eye so the average user doesnt see it (dont believe me look at the 302 redirect headers sent when you click the msnbc link) and has no idea they have actually visited msn.com in order to steal their msn cookie

more information about this exploit can be found here
http://www.pc-help.org/privacy/ms_guid.htm

http://online.securityfocus.com/news/83

i really wish that the /. would not link to msnbc stories as every reader is being exposed to this no matter what browser they use

of course if you block msid.msn you cannot access the msnbc site , basically if you wont let msn track you they wont let you in the site

yeah im anon cos who iam doesnt matter