Slashdot Mirror

multipath tcp
http://threatpost.com/multipat...
http://labs.neohapsis.com/2014...

I have long since given up the use of passwd's for DSA keys in ssh.

I had always considered Bob Beck's post the definitive guide concerning ssh'ing as root, but it seems a number of users feel otherwise.

http://archives.neohapsis.com/...

US: I cast... magic missile
China: Why you cast magic missile? There nothing to attack!

Dan J. Bernstein for DM!

Um sure....

Some observations about this bug:

1. Same guy, Tavis Ormandy, found both the Windows exploit and the linux kernel bug.
2. Kernel bug was a local exploit. Windows bug is remote exploit.
3. The kernel bug was publicly reported on 2009/08/13 and the fix had already been committed by Linus. I don't know when it was privately reported.

My main problem with most music player software today is the idea of a 'media library'. In order to play a file, you first have to put it in the library. I understand such a database has its benefits, but to me it is unnecessary complication of a simple operation. In fact, I do have a custom script for managing music files burnt to DVDs, but in the unix spirit I like to keep thing separate, so I am free to use different players.

Years ago, I made a web based mp3 jukebox called Grind!.

  If you've ever glimpsed at the utter clusterfuck of metadata in music files, you understand why there are databases. ID3 tags were often wrong or in a weird format. (Bonus points if the ID3v1 and the ID3v2 conflicted.), and FreeDB had a very annoying format back in the early 2000s when I did this. (Storing both title and artist information in the same field in a trivially extensible tagged metadata format is beyond stupid.)

Even if you fixed all the metadata and coupled it with each individual track by using ID3v2 or something like it (and you should in order to be a good citizen), you still need to cache the metadata outside of individual files for performance reasons. You don't want to have to crawl the disk, opening, seeking to the end, and reading and reading the last 1k or so, to list every artist in the music collection. Crawling a disk like this really slow.

That said, that the metadata store just needs to be consistent, but not overly tight. By overly tight, I mean the original music files have to be easily extractable. Back when I was made jukebox, most of the other web based jukeboxes were copying every mp3 into MySQL as a blob column for god awful reason. That's super dumb. All you need is the path to the file, after all, the file system already stores generic bytes. If the db crashes, you're super screwed. Especially when you consider that many people are going to delete their original files after they've been copied into the db, since music collections are large and there's no reason to keep two copies on a disk.

The other thing you'd like in a media library is the ability to get the metadata back out of the library. This is the main reason why you want to keep a copy of the metadata tightly coupled (i.e. integrated) with the media files. It's my data. I'll do what I want to with them.

In all honesty, iTunes does a relatively good of this. The media files are stored on the disk in an easily understandable form (i.e. hashed names) under ~/Music/iTunes/iTunes\ Music/ , and the metadata is stored in uncompressed xml file named ~/Music/iTunes/iTunes\ Music\ Library.xml The only thing I'm not sure about is the album artwork, and whether it updates the id3v2 tags to be consistent with the assumed correct information stored in the xml file. It's a good system. It's unixy.

> Windows 3.1 - 7 are often based on the same code set.

You, sir, do not have the vaguest idea of what you are talking about.

> to get into windows 3.1 you need to type in "win" at the DOS window.

I thought for a moment you meant Windows *NT* 3.1 - 7, but ... it's clear that you didn't mean that.

FWIW, this bug affects all NT OSes right back to NT 3.1 (the first released version) and is an obscure kernel bug (it was only found in January 2010!). The BBC article was light on details except to say it "involves a utility that allows newer versions of Windows to run very old programs", but there's more detail from the always-excellent full-disclosure mailing list.

Microsoft was informed about this vulnerability on 12-Jun-2009, and they confirmed receipt of my report on 22-Jun-2009. Regrettably, no official patch is currently available. As an effective and easy to deploy workaround is available, I have concluded that it is in the best interest of users to go ahead with the publication of this document without an official patch.

from Tavis Ormandy's disclosure

So the bug was found six months ago, but Microsoft only decided it was serious enough to fix after it was publicized. Seems like another case of "responsible disclosure" being used to cover up a vulnerability, instead of fixing it (or publishing a workaround) before the bad guys find out about it.

From http://archives.neohapsis.com/archives/fulldisclosure/2009-08/0174.html:

-------------------
Mitigation
-----------------------
Recent kernels with mmap_min_addr support may prevent exploitation if
the sysctl vm.mmap_min_addr is set above zero. However, administrators
should be aware that LSM based mandatory access control systems, such
as SELinux, may alter this functionality.
It should also be noted that all kernels up to 2.6.30.2 are vulnerable to
published attacks against mmap_min_addr.

I have checked my default Ubuntu and CentOS/RHEL boxes, and both of them are set well above 0:

root@Ubuntu:/proc/sys/vm# cat mmap_min_addr
65536

[root@CentOS /proc/sys/vm] cat mmap_min_addr
65536

[root@RHEL /proc/sys/vm] cat mmap_min_addr
65536

From http://archives.neohapsis.com/archives/fulldisclosure/2009-08/0174.html:

-------------------
Mitigation
-----------------------
Recent kernels with mmap_min_addr support may prevent exploitation if
the sysctl vm.mmap_min_addr is set above zero. However, administrators
should be aware that LSM based mandatory access control systems, such
as SELinux, may alter this functionality.
It should also be noted that all kernels up to 2.6.30.2 are vulnerable to
published attacks against mmap_min_addr.

Then why did Linus check in a patch today to fix it?

http://archives.neohapsis.com/archives/fulldisclosure/2009-08/0174.html

Linus committed a patch correcting this issue on 13th August 2009. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e694958388c50148389b0e9b9e9e8945cf0f1b98

Here's the real one- linked from (mostly) useless article.
http://archives.neohapsis.com/archives/fulldisclosure/2009-08/0174.html

If I control ALL your traffic, I can operate as a full proxy for any of it. Your client will see a certificate that it sees as valid, because I can spoof ALL the lookups. The only way around this is using PFS. Don't take my word for it, Google, and learn. EG: http://archives.neohapsis.com/archives/sf/ids/2007-q1/0081.html http://www.mail-archive.com/wireshark-dev@wireshark.org/msg08722.html

You're comparing apples with oranges. Postfix is a fully fledged, general purpose MTA, here, right now. It has seen non-trivial evolution the years, and succeeded in providing several features that didn't exist 10 years ago (Milter, pluggable SMTP authentication, TLS, Multi-database connectivity, ...).

Evolution does not come for free, actually. The code has to be maintained, and new features written. In all these years, Postfix has increased the size of its code base several times [1] [2]. If you must compare its security record, then *please*, do a fair comparison. Pick some other project, with similar, real-world requirements, then come back and re-consider your statements.

[1] http://archives.neohapsis.com/archives/postfix/2006-07/1762.html
[2] http://www.irbs.net/internet/postfix/0607/1777.html

Flawed? So what's the nature of this flaw? Well, it doesn't really, well, work. Not as such. Not as such. Yeah, we've heard there's some BSD firewalls already out there, and apparently some of them are supposed to be pretty secure, but... hell, we don't need firewalls, this is a Mac! And, as the strip "Osama Bin Laden's Computer Nightmare" in the latest issue of Viz so perspicaciously pointed out, Macs can't get viruses.

http://archives.neohapsis.com/archives/fulldisclosure/2005-09/0411.html

"software which OpenBSD uses and redistributes must be free to all (be they people or companies), for any purpose they wish to use it, including modification, use, peeing on, or even integration into baby mulching machines or atomic bombs to be dropped on Australia" — Theo de Raadt

http://archives.neohapsis.com/archives/openbsd/2004-06/0448.html

1. The point is that popularity is not the only or even the primary reason why a product can be attacked.
1a. Back in the old "classic" Mac era the Mac went through a period where it was the prime target for attacks, despite it having a fraction of the market, simply because it had such a huge surface area to attack.
1b. Apple responded to many exploits (for example, in autorun CDs and floppies) by removing dangerous capabilities.
1c. Similarly, UNIX systems usually don't come with the "r" suite enabled or often even installed any more.
2. The problems I listed have not been fixed or even addressed by Microsoft.
2a. Windows is still vulnerable to autorun attacks in CDs and USB keys.
2b. Windows still comes with dangerous components like SMS.
3. http://archives.neohapsis.com/archives/fulldisclos ure/2005-04/0400.html

"NT4 was a nice operating system for SCADA applications. It was built in a time where Microsoft cared about security"

NT security rating only applied to a stand-alone version on specific hardware and no network support.

'Because of Davis-Besse's widespread use of vulnerable Microsoft software, the worm jumped to the plant network and crashed the Safety Parameter Display System, keeping it offline for eight hours," Paller testified'

was: Re:NT4 On The Plant Floor

One IP number can represent dozens of name virtual hosts. So if you count IP numbers you get stats favoring IIS, which has closer to a 1:1 ratio (or worse) of machine to web presence. If you count hostnames, you get stats favoring all other HTTP servers.

And if you limit your survey to HTTP compliance then you eliminate all IIS sites. Add in TCP/IP compliance and you eliminate anything hosted on MS Windows, accidentally, out of ignorance or otherwise not just IIS but also Lighttpd and Apache.

For the curious... The article links to a another page with the passwords here

Too lazy to look... root is "dottie" and the user mobile is "alpine".

Here's the Debian bug for PAM

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3 35273

Basically, segfault if you used pam_tally, which was a security requirement where I work. Took a year to be fixed.

http://packages.debian.org/changelogs/pool/main/p/ pam/pam_0.79-4/changelog

Yes, we're talking about volunteers, but still--a bug in the core login system that can lock you out of your remote server permanently is pretty severe to be leaving lying around for a year. If you do a search on Google, there are plenty of other people who were bitten by it; e.g. http://archives.neohapsis.com/archives/pam-list/20 06-02/0006.html

I didn't report the X.org bug, but as I say, it was apparently specific to FireGL T2, which is probably why you didn't see it. A search for "X.org FireGL T2" picks up a bunch of other people who had the problem. (That one was also in Ubuntu, granted.)

http://archives.neohapsis.com/archives/fulldisclos ure/2007-01/0282.html

now please shut down google?

oh I see, they are corporate and fydor is the little guy, I forgot!!!

changing it to something public could be a sign of knowing what you are doing, and i believe the main defence is ignorance of how to do these sort of things.
on the other hand the most common configuration is to use a dhcp server. The IP address of a computer connected direct to a cable modem is what the cable modem assigns it(well strictly speaking what the isp assigns the cable modem). put a router inbetween and the router assigns the PC an address.
Does the Event Log on an Xp home system maintain a history of past IP addriesses? I'll admit I do not know, however this link I found does detail a vunerability in windows 2000 and XP http://archives.neohapsis.com/archives/vulnwatch/2 001-q4/0042.html
"an interesting quote from that link
Another issue here is the fact that IP addresses logged by Terminal
Services and/or the Event Log are no longer credible and therefore
hardly useful as evidence in a court of law. "

One line of questioning I might be tempted to use is about the existance of botnets and related exploits if examination showed evidence of a remote takeover that would be an aid to her defence and a negative finding is inconclusive. Windows barely makes it as secure even when administered by 'experts' a failure to look for such evidence or recognise the possibility of misuse of an unknown third party would weaken the procecutions case.
routed to or routed through the defendents IP address.

Here's one way to work around the problem, with postfix http://archives.neohapsis.com/archives/postfix/200 4-01/1944.html

NGS have of course done work on SQL Server for Microsoft; I refer you to the brief and rather one-sided flamewar on Bugtraq/FD that erupted when this was pointed out... actually see for yourself... (and here's the Bugtraq thread). I predict this will deal with 75% of the "but this is nonsense, because..." posts ;)

He's got a lot of credibility. This is the point I'm trying to make :)

NGS have of course done work on SQL Server for Microsoft; I refer you to the brief and rather one-sided flamewar on Bugtraq/FD that erupted when this was pointed out... actually see for yourself... (and here's the Bugtraq thread). I predict this will deal with 75% of the "but this is nonsense, because..." posts ;)

He's got a lot of credibility. This is the point I'm trying to make :)

No I wasn't. This disclosure was announced in May 2005 when HTT was enabled.

It's disabled since then and, if you want it, you need to enable it with sysctl (machdep.hyperthreading_allowed)
http://archives.neohapsis.com/archives/freebsd/200 5-05/0037.html

Cheers.

SMB was based on (really copied from) an old DEC protocol. This is what jump-started the Samba project; one of the lead developers had access to DEC's specs for this protocol.

No. DEC had an implementation of SMB called PATHWORKS, which included a DOS client and a server for VMS and, I think, Ultrix, but they didn't invent the protocol. (They might have had some add-on protocols with PATHWORKS, but the core protocol was the SMB that IBM, 3Com, Intel, and Microsoft were involved with developing. See this message from Steven French. I think Steve's the main developer of the cifsfs in-kernel SMB client for Linux).

One of the lead developers (some guy named "Andrew Tridgell" :-)) reverse-engineered SMB based on traffic between the PATHWORKS client and server; he later discovered that this was SMB, which did have some published specs. See Tridgell's description of the history of Samba.

They were file infecters, and also installed listeners and phoned home. They tried to use a couple of minor stealth features, but I don't think you could call them rootkits.

RST.a
RST.b
OSF

ZoneAlarm is trivial to bypass with a WSH / VBS script or any other way of sending windows messages. I.e. virtually every windows programming language. All "personal firewalls" that I know of are vulnerable to the same approach. Use of non-standard widgets etc could complicate this attack but I can't see any obvious way to prevent it entirely.

ZoneAlarm example

Also it used to be vulnerable to process memory injection, they've probably fixed that by now though.

Here's a threaded view of the Full Disclosure thread, rather than the first follow-up post to Dave Korn's OP, which the story submitter seems to have decided would be a better way... http://archives.neohapsis.com/archives/fulldisclos ure/2006-04/thread.html#268

if you goto the Windows Live.com site (hxtp://safety.live.com) to stop this malicious program/worm the MS site uses a malicious cookie exploit against you, if you deny the exploit you cant get to the site to get help

its like a Hospital saying "we have to break your leg so we can fix your arm"
they should be ashamed

Oh my, big words. Just read the list of vulnerabilities in the updatelist on, say, Ubuntu, and you'll see alot of patches for kernel exploits. From last summer (I gather this has not changed that much since june): Linux kernel exploits

Re: Theo gave an interview to Forbes Mag. about Linux

From: Theo de Raadt (deraadtcvs.openbsd.org)
Date: Fri Jun 17 2005 - 11:13:37 CDT

* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

> On Fri, Jun 17, 2005 at 04:48:31PM +0200, J. Lievisse Adriaanse wrote:
> > Theo gave an interview to Forbes Magazine, in which he stated: "It's
> > terrible," De Raadt says. "Everyone is using it, and they don't
> > realize how bad it is. And the Linux people will just stick with it
> > and add to it rather than stepping back and saying, 'This is garbage
> > and we should fix it.'"
>
> Heh. Theo never did pull his punches. I suppose there's now a war going
> on in /. ? :)

If the Linux people actually cared about Quality, as we do, they would
not have had as many localhost kernel security holes in the last year.

How many is it... 20 so far?

Anyone who uses Cross-Over Office, Cedega, or plain old Wine (all 10 of you) -- your system is vulnerable to the recent WMF exploit. Loading an office document in Cross-Over that has an embedded WMF file will execute arbitrary code on your system. Gamers -- any games that display user-defined graphics (avatars, etc) and accept the WMF/EMF formats, could be exploitable. A patch was submitted to the Wine development team, but it may not be available for a while (especially if you use a commercial derivative). Please see the following URL for more information:
http://archives.neohapsis.com/archives/fulldisclos ure/2006-01/0173.html

The - final? - twist in the long, strange trip of the WMF bug - the vulnerability that just keeps on giving - has been revealed by H D Moore, the author of the Metasploit exploits (which is now on a third generation and even tricksier than ever!:)

After all the jokes about WINE compatibility... it turns out that WINE is vulnerable, too!!

To quote the words of a song by H D's namesake, Dudley:

Laugh? We nearly shat
We had not laughed so much since Grandma died
Or Aunty Mabel caught her left tit in the mangle...

(And I'm posting from a Thinkpad running Mandriva GNU/Linux, the first time I've been 100% Billy free at work as well as at home since 2000, so I'm allowed to laugh... no WINE for me cos I only run Free software *smug* :)

According to this post there are cases where you often get much better results with rzip than bzip2. So testing also depends on the type of data one expect to compress.

Microsoft said Spooler was most likely just a DoS. Immunity Inc. let people know that was not true; the Spooler vuln was reliably exploitable remote root code exec & working exploit code was clearly in existence prior to or at least at the time of patch release.

At the time, a few months ago now Dave Aitel from Immunity Inc. said "Linux vulnerabilities are a thousand times harder to exploit than Windows vulnerabilities", and "'many eyes' have reduced Linux to a fished out pond, whereas things like strncpy() bugs are highly likely to still be around in remotely accessible (Microsoft Windows) components."

The following link seems to suggest that Microsoft (as of q3 2005) did not understand or worse misrepresented the "root source of vulnerablility" for Spooler; a critical security risk. Perhaps one could argue that Linux style patch transparency would have made that vulnerability/exploit far more publicly visible and would have resulted in fewer people being misled into believing it was a less severe risk (only a DoS, hah).

http://archives.neohapsis.com/archives/dailydave/2 005-q3/0221.html

How much value do you place in the fact that Linux patches are always made available in source code form? Do you think that those "many eyes" Aitel talks about bring greater scrutiny to Linux bugs when they become publicly known? Do you think the nature of Linux patches results in a better or worse understanding of vulnerabilities and true risks?

http://secunia.com/product/22/
Currently, 27 out of 122 Secunia advisories (for Windows XP Professional), is marked as "Unpatched" in the Secunia database.

Microsoft said Spooler was most likely just a DoS. Immunity Inc. let people know that was not true; the Spooler vuln was reliably exploitable remote root code exec & working exploit code was clearly in existence prior to or at least at the time of patch release.

At the time, a few months ago now Dave Aitel from Immunity Inc. said "Linux vulnerabilities are a thousand times harder to exploit than Windows vulnerabilities", and "'many eyes' have reduced Linux to a fished out pond, whereas things like strncpy() bugs are highly likely to still be around in remotely accessible (Microsoft Windows) components."

The following link seems to suggest that Microsoft (as of q3 2005) did not understand or worse misrepresented the "root source of vulnerablility" for Spooler; a critical security risk. Perhaps one could argue that Linux style patch transparency would have made that vulnerability/exploit far more publicly visible and would have resulted in fewer people being misled into believing it was a less severe risk (only a DoS, hah).

http://archives.neohapsis.com/archives/dailydave/2 005-q3/0221.html

How much value do you place in the fact that Linux patches are always made available in source code form? Do you think that those "many eyes" Aitel talks about bring greater scrutiny to Linux bugs when they become publicly known? Do you think the nature of Linux patches results in a better or worse understanding of vulnerabilities and true risks?

SANS Top 20, November 22, 2005 is here.

This is the first year that they are pulling out specifically application and network devices/software. However, to anyone who reads Bugtraq, Full Disclosure, or VulnWatch, this is incredibly old news.

I suspect that the new attention is partly due to marketing and partly due to better tracking facilities by ISC.

SANS Top 20, November 22, 2005 is here.

This is the first year that they are pulling out specifically application and network devices/software. However, to anyone who reads Bugtraq, Full Disclosure, or VulnWatch, this is incredibly old news.

I suspect that the new attention is partly due to marketing and partly due to better tracking facilities by ISC.

SANS Top 20, November 22, 2005 is here.

This is the first year that they are pulling out specifically application and network devices/software. However, to anyone who reads Bugtraq, Full Disclosure, or VulnWatch, this is incredibly old news.

I suspect that the new attention is partly due to marketing and partly due to better tracking facilities by ISC.

Just one link, but it should speak for itself:

http://archives.neohapsis.com/archives/fulldisclos ure/2004-06/1004.html

KBB, by choosing to run IIS, infected every web visitor of theirs one fateful day. Do you want to be _that_ guy?

Here is a concrete payoff of OpenBSD pro-active stance with respect to security: fixed early 2004.

It is pretty common to fix these sorts of bugs it complicated protocols like ISAKMP.

Yeah, complicated protocolls implementations are particularly suspectible to format string vulnerabilities and buffer overflows....

The advisory says:

Multiple ISAKMP implementations behave in anomalous way when they receive and handle ISAKMP Phase 1 packets with invalid and/or abnormal contents. By applying the OUSPG PROTOS ISAKMP Test Suite to a variety of products, several vulnerabilities can be revealed that can have varying effects.

The OpenBSD developers fixed this early 2004 :

> I just tested our isakmpd(8) implementation against the PROTOS
> test suite. No problems were detected. We performed an audit
> of isakmpd's IKE parsing code back in early 2004 and made several
> fixes (OpenBSD 3.4 timeframe).
>
> I also ran the PROTOS suite against tcpdump -vvv and saw no
> problems.

Please also note that both these programs are priv sep'd, so that
in the event a bug is found, the impact will be much reduced.

Can't help myself from quoting Theo de Raadt (in an otherwise unrelated post):

Ah, an American speaks.

SATAN and SAINT were never free (please read their license, I know, I packaged them for Debian and eventually dropped them. The first one because it was non-free, the second one because it claimed to be GPL when it was an unauthorised SATAN fork. Same for SARA. Sure, they have s/satan/saint/g or s/satan/sara/g (even on the script names) if anyone wants to compare sources, let me know, I've been tracking all of them since SATAN was last released.

It just seems that Dan Farmer and Wietse Venema don't care about these forks, they abandoned SATAN a long time ago (it's not even available in fish.com anymore, the domain is no more). I know, I contacted them.

You fail to see two sides of Nessus here, which might lead to it being eventually being dropped from Debian. Be it a vulnerability scanner, an antivirus or an IDS yo uhave:

• the engine
• the rules

An engine without rules is not useful at all. And Tenable closed-source those already a while back. Just like Sourcefire closed sourced the Snort rules.

Quite sincerely, If I were the Debian maintainer (ehem), I would consider dropping support for both packages in Debian even though I believe it would be as much a loss to Debian users as to the projects themselves (less user-base => less exposure => less bug reports => less enhancements => .... => product dead?). It seems that Sourcefire, however, now has Check Point to sustain the project and fund its development even if the OSS crowd turns away from it.