Slashdot Mirror

The point of the article is that while the base system may indeed be very secure, it is practically useless.

1998 called, they want their rationalization back. Besides, just about everyone turns off SELinux when they want to actually get work done.

Is lighttpd any more secure on OpenBSD than on Linux? No.

Good thing they have an audited, privsep, chrooted version of Apache, then.

With SELinux, you need not only a local privilege escalation, but a hole in SELinux as well.

Bullshit.

I would argue that OpenBSD may be secure by design, but SELinux is, in practice, more secure.

Adding complexity rarely increases reliability.

I would be absolutely ecstatic if OpenBSD implemented something more like SELinux in terms of privilege separation.

The Stephanie project worked towards doing just that, but it appears the project died several years ago.

Well there's a research project over at FreeBSD that may be useful:

http://www.cl.cam.ac.uk/research/security/capsicum/

Perhaps it will be ported to other operating system. From the USENIX video, it looks quite promising:

http://www.youtube.com/watch?v=raNx9L4VH2k

If the GP wants SELinux, he could always use TrustedBSD:

http://www.trustedbsd.org/sebsd.html

The point of the article is that while the base system may indeed be very secure, it is practically useless.

1998 called, they want their rationalization back. Besides, just about everyone turns off SELinux when they want to actually get work done.

Is lighttpd any more secure on OpenBSD than on Linux? No.

Good thing they have an audited, privsep, chrooted version of Apache, then.

With SELinux, you need not only a local privilege escalation, but a hole in SELinux as well.

Bullshit.

I would argue that OpenBSD may be secure by design, but SELinux is, in practice, more secure.

Adding complexity rarely increases reliability.

I would be absolutely ecstatic if OpenBSD implemented something more like SELinux in terms of privilege separation.

The Stephanie project worked towards doing just that, but it appears the project died several years ago.

Tavis disclosed the ntvdm vulnerability in January, however it was reported to Microsoft on June 12, 2009.
http://lists.grok.org.uk/pipermail/full-disclosure/2010-January/072549.html

Gaping security hole? You mean this? Sounds like a dupe of this hoax.

A very scary thing about Google is that if your cookie is stolen once it can be misused for weeks. Even if you log out to terminate your session the server would still keep your session alive. A hacker can still use the stolen cookies to misuse your account. So it is very much safe to use other sites like Yahoo, etc. who terminate the session in the server.

There is a very interesting article on this at: http://lists.grok.org.uk/pipermail/full-disclosure /2007-July/064649.html

It looks that way to me.

Unless this is a different vulnerability, Debian applied the fix over four months ago, two days after the patch was available, and eight days after the vulnerability was first reported

I saw the article and immediately started aptitude to get the fix, only to discover that I already got it, two weeks before Christmas. Nice.

As do theregister, theregister, attrition.org, attrition.org, grok.org.uk,

Even mi2g's own research FTA:

The firm estimated that, with around 600 million Windows-based computers worldwide, this works out at between $281 to $340 worth of damage per machine.

Wow. That is a lot of money per Windows box, per year. To do as badly in sum, every linux box on the interweb would pretty much have to commit fusion.

"Windows computers in over 200 countries were infected. Judging by events which unfolded between January and April 2004, there could be a choppy cyber-sea ahead, made all the more complex by new and more dangerous malware families yet to emerge."

The top 10 malware programs of all time, according to mi2g, are MyDoom, Netsky, Sobig, Klez, Sasser, Mimial, Yaha, Swen, Love Bug and Bagle.

Of course, none of those programs run on OSX or linux.

"It serves the purpose of the vendors to blame the users or the virus writers and not themselves for designing 'Swiss cheese' software."

Don't you MS bloggers have anything better to do? Could you maybe have a look at that virgin Vista IP stack for us? We're a little worried you guys were trolling slashdot and not FIXING THE DAMNED BUGS.

Countdown to the phisher finding a way to subvert the system and obtain legitimate certs to green-light their scam sites :
4... 3... 2... 1...

Informative reading :

http://lists.grok.org.uk/pipermail/full-disclosure /2006-June/047380.html

Rob, I'm sorry about all those times we terrorized your network with banbots and the DCC SEND exploit.

I'm sorry that after Grog took over freenode by convincing you he was Greg Lehey of FreeBSD I took the liberty of impersonating your caller ID and voice to shout obscenities and insults on Greg's voicemail.

I'm sorry that you never learned to use SSL or SSH and we pulled your oper block password off the wire.

I'm sorry about the time I pulled all your docs, released your SSN on the full-disclosure mailing list and gave your credit cards and checking account number to third world hustlers. That was really mean.

Most of all, I'm sorry you're dead because I'll have to find someone new to troll.

RIP Rob Levin, trolled to death by car.

(response from Safari user) *cough* Obtain an interactive shell through lynx *cough* Lynx NNTP vulerability *cough* Lynx CRLF injection*cough*

Excerpt from http://lists.grok.org.uk/pipermail/full-disclosure /2005-November/038646.html :

*********

1) Skype will initially attempt to contact supernodes, the IPs of which
are in a file stored along with the other files that Skype installs. The
first method of contact is direct. The source ports that Skype attempts
to connect from are non-default ports. From my observations I could see
that the UDP source port 1247 is the initial control channel. Once the
connection is established, the rest of the communications is done in TCP
over non-default source ports with ranges sweeping from 2940-3000.
In general, any company that is serious about its security policy would
have strict egress filtering rules, which makes identifying the
non-default source/destination ports that Skype uses irrelevant since
they would be blocked anyway.

2) If the above fails, Skype will use the proxy server specified in Internet
Explorer, and attempt to tunnel the traffic over port 443 using the SSL
protocol. The destination IPs are of course random as above, which makes
destination blocking out of the question. The only option left is to
block SSL,
which is not really a solution, unless you want to end up excluding all
legal SSL destinations.
Deleting the user's proxy settings would also disallow Skype from
connecting. That would however leave the user without internet access.
Even if the user had no proxy settings, and the proxying was done
transparently (which would definitely include proxying http and https
traffic), the Skype traffic (SSL) would again be transparently proxied,
which puts us back at square one.

********

The aforementioned link however speaks of a somewhat twisted method of blocking out skype by restricting outbound HTTPS to only the requests adressed by FQDN.

Perhaps Skype will eventually just use SSL over 443 for the whole of the communication in order to establish connections, which is quite an effective method of bypassing any kind of firewall or filter put in place by a corporation. And the same technique holds true for any other "undesirable" protocol. With VPNs now starting to use SSL over 443 to evade restrictive outbound ACLs, it's getting more difficult to restrict what leaves your network.

It happened once in 2003, but I can't recall any other incidents. That time it was a previously unkown Linux kernel hole which was used to gain root along with a sniffed password.

This time it looks like another kernel hole - but we've not had public confirmation. Could have been been an exploit for CVE-2006-2451...

I see many people saying that it is a good thing that it can not be blocked. Understand that you can also send files by skype.
So all I have to do is write a virus that uses skype to send a package with skype.

The other person gets the program with Skype. If you use something like LISA, you could even let it talk to the other person.

Filtering solution

Skype has done a pretty good job of creating a protocol that works in almost all situations, unlike SIP or many other VOIP technologies. You don't have to worry about NAT full-cone, restricted-cone, port-restricted cone, STUN, or any other crap in a badly designed protocol.

However, if you want to block skype, it is very easy. Have a look at reports using openbsd & squid.

Or do a quick search with google.

When I said critical I meant vulnerabilities that could cause the server to be compromised. IIS6 had never had any.

Now lets analyze your last post...

"How about a buffer overflow exploit? Doies that count?
http://lists.grok.org.uk/pipermail/full-disclosure /2005-April/033445.html"

Sorry, but that one does count because it's not real.

"How about this long list as compiled by a Microsoft MVP?
http://msmvps.com/blogs/bernard/archive/2004/06/10 /7882.aspx"

That list counts every vulnerability in Win2k3 since it was released, and is not relevant. IE/Media PLayer/Flash/SMB vulnerabilities cannot be exploited via IIS6.

"How about these honorable mentions as well?
http://www.aqtronix.com/Advisories/AQ-2003-02.txt (unannounced by Microsoft)
http://isc.sans.org/diary.php?date=2005-10-11
http://www.securityfocus.com/bid/9409"

Hmm. The first is a IIS5 vulnerability. Try reading past the first line next time.

The second one is not an IIS6 or IIS5 vulnerability. Not sure WTF you posted that for.

The third one is an Exchange Vulnerability. Exchange != IIS6

"Lets also not forget that....several vulnerabilities to underlying systems and Dlls caused IIS6 to be vulnerable as well."

Just because some dll or binary is vulnerable in Windows does not necessarily mean it can be exploited via IIS. You are grasping for straws here.

So lets sum your glorious rebuttal to my claim that IIS6 has had no critical vulnerabilities.

* You've posted a fake (Here's your sign!) vulnerability.
* You've posted a list of all of the vulnerabilities in Win2k3, and insinuated that they all can be exploited via IIS6
* You've posted two vulnerabilities that had nothing to do with any version of IIS, and one IIS5 vulnerability.
* You repeatedly brought up IIS5, when in fact I never brought up IIS5 and was specifically talking about IIS6.

Faster? Perhaps, but by who's measure? I've never seen a useful (yes, Microsoft's don't count as useful) Apache/IIS performance comparison.

More secure? Why do you think that? IIS6 has never had a critical vulnerability discovered for it. In the same time frame you can't say that for Apache 1.x and 2.x.

We believe in it.

The GNAA Security Center released working exploit code for the Xanga blogging service (which, I might add, predates MySpace by quite a long time, and maybe LJ too).

This exploit works because Xanga lets users insert Javascript codes into their websites. A malcious user just needs to add the code to their "Look and Feel" control panel and then the Javascript code will send the login cookies of anyone who visits their page to a remote server. Xanga has rudimentary JS filtering of "bad" functions but these filters can easily be bypassed by using the document.print method to write out the bad code across several calls (i.e. document.print("");). Xanga knows about the problem but will not fix it.

This code was used to breach security of several Xanga administrators for many months.

http://lists.grok.org.uk/pipermail/full-disclosure /2005-December/040473.html

...who works for 180solutions. Well, I didn't really know him until I flamed him on full-disclosure for working for 180solutions, but that's beside the point. This guy was totally for 180solutions! I could hardly believe my ears... er.. eyes! I reminded him of the incident where 180solutions was using browser flaws to install adware on victims' machines, yet he had "no recollection of any such event" (even though it was all over the internet and widely discussed on security mailing lists). The nerve of some individuals... Some people just deserve to be shot.

Yup, even running a good firewall won't work, it seems media sentry has been known to not actually connect to see if the client is truly sharing. They just look at the stream to see the IP addresses of everyone connected. It's the downside of the Bittorrent protocol, it's not great for identity based security.

Yup, even running a good firewall won't work, it seems media sentry has been known to not actually connect to see if the client is truly sharing. They just look at the stream to see the IP addresses of everyone connected. It's the downside of the Bittorrent protocol, it's not great for identity based security.

It looks like that buffer overflow might be there, but it depends on stuffing lots of data into the RELAYCLIENT environment variable. Because qmail-qmtpd does not have the setuid bit, RELAYCLIENT must be set by root or the daemon user prior to dropping root. Hence this bug is totally unexploitable.

http://lists.grok.org.uk/pipermail/full-disclosure /2004-March/018191.html

But I agree with the sentiment - oh so close!

Let's just say that I admire how much resources it takes under NT to spawn one new process. In fact I'm positively astonished. A good thing? I think not.

Can I ask: in your tests of resource usage for process spawning in NT, which API did you use? There are multiple process spawning APIs available, and to get good performance you will need to avoid using the backwards compatible "CreateProcess" or "CreateProcessEx" APIs and go directly to the kernel level variants.

The CreateProcess family of calls are not designed for the specific case of forking an existing process, but instead are intended as a 'fork & exec' kind of call. Some systems (e.g. cygwin) have been known to use them to emulate fork, but this is not really a good way of doing it.

I'm also in awe of the way the NT kernel is virtualized and compartimentalized. Wait, it's not. You do know, don't you, that a Sun E15k with an arbitrary number of CPUs under Solaris can be split any which way (dynamically even) as virtual computers?

OK, so Solaris supports a feature that NT doesn't. I'm afraid I don't get your point. Different systems have different feature levels, and different price points. You can't expect total equivalence of such things. (Out of interest: can Solaris do this on x86 machines?)

Is it the TCP/IP stack that you admire? Hmm, where was that taken from again?

The Windows TCP/IP stack is not taken from BSD code, at least not the version in present editions of windows.

In fact what's so special about NT, with or without win32, that is so good? Is there a single piece that no one else has?

No other platform is so widely installed. There is little wrong with the platform (at least at the kernel level). The platform supports a wider variety of low-cost peripheral devices than any other. These factors are enough to make it the best platform for many applications. As long as your application doesn't require top end features that it doesn't implement (e.g. processor partitioning) or doesn't require it to be secure in a public-facing environment, it's a good choice. Even the latter problem can be mitigated substantially by installing a slimmed down version (e.g. XP Embedded).

OK Mr Doubting Thomas ... the hack was disclosed on Full Disclosure on May 23rd.

There is lot of hype about WGA (Windows Genuine Advantage) when Microsoft builds functionality in its few of the public beta products to conduct a genuine product check before the product gets installed. MS products or tools with WGA check enabled can only be installed on a valid / genuine copy of MS Windows XP. Incase it is a pirated copy then the product denies to install.

If you are aware of Microsoft WGA validation then you can directly jump in to the PoC section otherwise it is advisable to read on WGA and what it does before reading the PoC.

To know more about WGA, refer to the following Microsoft link: http://www.microsoft.com/genuine/downloads/FAQ.asp x?displaylang=en

Defeating Microsoft WGA Validation Check - Proof of Concept (PoC) This PoC explains how Microsoft WGA validation check can be defeated and any Microsoft product with the WGA validation feature can be run and installed on machines running pirated copy of Windows XP. To bypass WGA validation check, one can run "GenuineCheck.exe" file on a machine running a copy of an authentic Windows XP for generating a key code. This key code generated on the machine running genuine copy of Win XP can be used to circumvent the WGA check on the machine running a pirated copy of Win XP.

A detailed approach can be downloaded from the following link - http://www.hackingspirits.com/vuln-rnd/defeating-w ga-check.zip

Microsoft in its reply to my mail specified that "The generated code is partly made up of a timestamp, which would prevent use after a short period". However, I checked this on a pirated copy of Windows XP Pro and installed couple of public beta products and tools for testing purpose. They are still up and running since past 1.5 months.

Incase, anyone is going to try this out on their pirated versions of Win XP then do let me know if the installed product make noise after certain time period.

ð Debasis Mohanty ð www.hackingspirits.com

This was discovered by multiple people months ago, as evidenced by this full-disclosure thread, with a followup by another discoverer of the same exploit.

This was discovered by multiple people months ago, as evidenced by this full-disclosure thread, with a followup by another discoverer of the same exploit.

There was discussion on this on the Full-Disclosure mailing list when posters suspected that the 100% CPU usage on their computers was because of some new unknown virus.

A repesentative of Trend Micro Germany made a post to the thread where he explained the situation, apologized for it and offered pointers to their support database so that people could get the malfunctioning virus signatures uninstalled.

There was discussion on this on the Full-Disclosure mailing list when posters suspected that the 100% CPU usage on their computers was because of some new unknown virus.

A repesentative of Trend Micro Germany made a post to the thread where he explained the situation, apologized for it and offered pointers to their support database so that people could get the malfunctioning virus signatures uninstalled.

There was discussion on this on the Full-Disclosure mailing list when posters suspected that the 100% CPU usage on their computers was because of some new unknown virus.

A repesentative of Trend Micro Germany made a post to the thread where he explained the situation, apologized for it and offered pointers to their support database so that people could get the malfunctioning virus signatures uninstalled.