Slashdot Mirror

Is it just me, or is the Slashdot "unofficial patch" link at the top absolutely useless?

After banging around the SANS site for a good 15 minutes, I *finally* found WHERE YOU CAN DOWNLOAD THE PATCH from:

http://isc.sans.org/diary.php?storyid=999
http://isc.sans.org/diary.php?storyid=1004

Should I just block all .WMF images?
This may help, but it is not sufficient. WMF files are recognized by a special header and the extension is not needed. The files could arrive using any extension, or embeded in Word or other documents.

From here

So blocking WMF files doesn't seem to help :(

In defense of our Slashdot overlord, it says "Trustworthy", not "Trusted". And it's not like Hemos made it up, either - that's the verbatim headlne SANS/Mr. Liston put on the article.

And the CPU usage is also basically a quote from the SANS site: "On busy networks, this will lead to 100% CPU utilization of the Snort process and major packet drops."
http://isc.sans.org/diary.php

I wouldn't call what they are offering as trusted computing. They are not the manufacturers of the OS, so whatever they are offering is NOT trusted computing.

"Trustworthy" was here used only as a saying. As in "Please, trust us". Please read the ISC diary entry.

Since it's a typical binary patch you have to trust them that this patch won't hose your system or make you pwned by these or other folks.

The patch is distributed by Ilfak Guilfanov, who develops the IDA Pro Disassembler and Debugger. The WMF fix installation package includes source code for the DLL it installs.

Look, when I want to upgrade my box, I just do a apt-get update; followed by either apt-get dist-upgrade or use synaptic. I know my sources (I select them myself), I know that the reality checks exist (gpg keys, outside sources verifying the software, etc.). I know I'm not getting hosed when I install software from my usual Debian repositories.

Sure, you use apt-update when your os vendor has relased a fix. But what do you do when no official fix is yet unavailable, as the situation is now for Windows users?

There is one important note in regards to ALL published signatures including this one. All these signatures will fail to detect the exploits when the http_inspect preprocessor is enabled with default settings. By default, the flow_depth of the preprocessor is 300 which is too short to cover the whole exploit. Should the exploit be transmitted on port 80 and http_inspect is enabled, no alert will occur. Note that it will still alert on any ports (using the all port sig below) that are not configured in http_inspect (ie FTP).

One solution is to add the statement "flow_depth 0" to the http_inspect preprocessor (actually the appropriate http_inspect_server line in the config). This will tell the preprocessor not to truncate the reassembled pseudo-packet, but it will have an adverse impact on performance. On busy networks, this will lead to 100% CPU utilization of the Snort process and major packet drops.

And you should've checked before saying it was all made up.

So we have to explain the joke again:
The title comes from the original note in the Handler's Diary. You see, it creates a mental tension between "Trustworth Computing", the lack of an official patch and ISC's "Please, trust us". It makes some readers smile.

The title come directly from the ISC's Handler's Diary post that uses it as a joke, to reflect the fact that they will ask people to trust them on this one. Quote:"I find myself in the very peculiar position of having to say something that I don't believe has ever been said here in the Handler's diary before: "Please, trust us.".

Since the only link to the patch appears on the SANS front page (and not on the blog page for some reason), here's a copy of it.

MD5: 14d8c937d97572deb9cb07297a87e62a

Okay then, how about https://isc.sans.org/index.php

But it was tested. And there is a a mention of the MD5 signature on this page:

http://isc.sans.org/diary.php?storyid=999

1. unregister the ms pic and fax viewer dll
2. make WMF file extension default to an erroneous app like notepad
3. turn DEP up a notch
4. turn off downloads in IE if you must use it (set default security settings to HIGH)
5. load unofficial patch at http://handlers.sans.org/tliston/wmffix_hexblog13. exe - make sure you check against the md5 hash!!
6. antivirus up to date, please check several times a day
7. block all WMF files at the perimiter

The SANS guys have reverse engineered it and given it the thumbs up if that's any help to you : http://isc.sans.org/diary.php?storyid=999

Ok, ignore my other message, I trust him.

From http://isc.sans.org/diary.php?rss&storyid=994 :

1. Microsoft has not yet released a patch. An unofficial patch was made available by Ilfak Guilfanov. http://handlers.sans.org/tliston/wmffix_hexblog13. exe Our own Tom Liston reviewed the patch and we tested it. The reviewed and tested version is available here (now at v1.3, MD5: 14d8c937d97572deb9cb07297a87e62a). THANKS to Ilfak Guilfanov for providing the patch!!
2. You can unregister the related DLL.
3. Virus checkers provide some protection.


To unregister the DLL:


* Click Start, click Run, type "regsvr32 -u %windir%\system32\shimgvw.dll" (without the quotation marks), and then click OK.
* A dialog box appears to confirm that the un-registration process has succeeded. Click OK to close the dialog box.

From http://isc.sans.org/diary.php?rss&storyid=994 :

1. Microsoft has not yet released a patch. An unofficial patch was made available by Ilfak Guilfanov. http://handlers.sans.org/tliston/wmffix_hexblog13. exe Our own Tom Liston reviewed the patch and we tested it. The reviewed and tested version is available here (now at v1.3, MD5: 14d8c937d97572deb9cb07297a87e62a). THANKS to Ilfak Guilfanov for providing the patch!!
2. You can unregister the related DLL.
3. Virus checkers provide some protection.


To unregister the DLL:


* Click Start, click Run, type "regsvr32 -u %windir%\system32\shimgvw.dll" (without the quotation marks), and then click OK.
* A dialog box appears to confirm that the un-registration process has succeeded. Click OK to close the dialog box.

Are The Internet Storm Center http://isc.sans.org/diary.php?rss&storyid=996 and F-Secure http://www.f-secure.com/weblog/archives/archive-12 2005.html#00000756 good enough for you?

Haha analysed by Steve Gibson, well NOW I feel safe. I think I'll take my advice from a proper security authority

This is the same basic exploit - but the seriousness and criticality is dramatically harder. A malicious file can contain any file extension of any random size and still be a WMF file on the "inside" and still have a "arbitrary code" payload. Most security groups are way freaked out now since IDS/IPS and AV patches are not patching this complete yet. Check out http://isc.sans.org/diary.php?rss&storyid=994 more a more indepth answer.

Since the first exploit came to light, H.D.Moore of the Metasploit project has reworked the original package they did. The new exploit spits out exploit WMF files that come:

• with a random size;
• no .wmf extension, (.jpg), but could be any other image extension actually;
• a random piece of junk in front of the bad call; carefully crafted to be larger than the MTU on an ethernet network;
• a number of possible calls to run the exploit are listed in the source;
• a random trailer

SANS/ISC have provided excellent continued summaries of events around this. Here's their FAQ on the issue.

This is looking truly horrible. On Tuesday morning zillions of Windows desktops will be fired up for the first time in a week or two. This thing's already in widespread use by a number of malware distribution networks for the usual reasons. As such it's a nightmare for network and system admins with Windows machines to look after (and us security people trying to provide advice & assistance for them...) But the stealth nightmare is that this is an absolute jackpot for the less visible targetted attacks, such as those emanating from China for the past couple of years (google around, Slashdot and Schneier have covered this as well as many other places.) There are also the opportunistic types who see an easy opportunity to pwn some key machines where they work, say. I will stick my neck out here and make a prediction. Virtually all organisations with Windows machines are effectively wide open to total compromise by a reasonably informed person. That means much of the IT dept as well as significant numbers of the 'interested poweruser' types, developers with a casual interest in security,.. anyone who's heard of this and is capable of running the findingm, running and using the new exploit, basically. Of course we're all tweaking our IDSes and antivirus, locking things down as tight as possible in the 48 hours remaining, but... *shudder*

For ten years I've been waiting for Microsoft's luck to run out. This is about #3 on my list of catastrophic MS incidents. There aren't many ways things could be worse.

It will be a good time to be running Linux on work machine, though :)

Since the first exploit came to light, H.D.Moore of the Metasploit project has reworked the original package they did. The new exploit spits out exploit WMF files that come:

• with a random size;
• no .wmf extension, (.jpg), but could be any other image extension actually;
• a random piece of junk in front of the bad call; carefully crafted to be larger than the MTU on an ethernet network;
• a number of possible calls to run the exploit are listed in the source;
• a random trailer

SANS/ISC have provided excellent continued summaries of events around this. Here's their FAQ on the issue.

This is looking truly horrible. On Tuesday morning zillions of Windows desktops will be fired up for the first time in a week or two. This thing's already in widespread use by a number of malware distribution networks for the usual reasons. As such it's a nightmare for network and system admins with Windows machines to look after (and us security people trying to provide advice & assistance for them...) But the stealth nightmare is that this is an absolute jackpot for the less visible targetted attacks, such as those emanating from China for the past couple of years (google around, Slashdot and Schneier have covered this as well as many other places.) There are also the opportunistic types who see an easy opportunity to pwn some key machines where they work, say. I will stick my neck out here and make a prediction. Virtually all organisations with Windows machines are effectively wide open to total compromise by a reasonably informed person. That means much of the IT dept as well as significant numbers of the 'interested poweruser' types, developers with a casual interest in security,.. anyone who's heard of this and is capable of running the findingm, running and using the new exploit, basically. Of course we're all tweaking our IDSes and antivirus, locking things down as tight as possible in the 48 hours remaining, but... *shudder*

For ten years I've been waiting for Microsoft's luck to run out. This is about #3 on my list of catastrophic MS incidents. There aren't many ways things could be worse.

It will be a good time to be running Linux on work machine, though :)

There's a patch available here

There is information available on temporary fixes from the following sites
http://isc.sans.org/diary.php?rss&storyid=996
http://www.f-secure.com/weblog/#00000760
http://www.grc.com/sn/notes-020.htm

be aware the runnable patch is completely unofficial, the only action microsoft suggest is unregistering a vulnerable dll which only mitigates the most common method of exploitation while not fixing the underlying problem.
NFI how long it will take microsoft to have an official patch out, but from the sans site, it doesnt look promising that it will appear soon.

Acording to the SANS Internet Storm Center: "Even if you un-register the DLL, some programs may re-register it by invoking it (shimgvw.dll) directly."

""Kye-U also has released a filter for proxomitron that will block wmf file downloads[....]"

Careful, The folks at the Internet Storm Center are warning that Windows often ignores the file extension and reads the 'magic bits' at the beginning of the file to decide how to process it. This means that someone could rename a .wmf to .jpg, for example, in order to get it past that filter.

The best workaround currently available is to un-register the shimgvw.dll as suggested above.

Internet Storm Center Coverage - Alert moved to yellow as of this morning. http://isc.sans.org/diary.php?rss&storyid=975
Also, take a look at this movie from websense: http://www.websensesecuritylabs.com/images/alerts/ wmf-movie.wmv it shows step-by-step what happens to a clean machine as it gets exploited by this new menace.

I'm amazed that more /. folks don't frequent http://isc.sans.org/ They've been on Yellow Alert most of the day due to this one.

what cheap or free monitoring options are there available . . .

If the network is the issue, the cheapest and simplest is a good laptop running Ethereal or Snort. Also pick up (or scrounge up) a dumb hub and if possible a fiber tap, since you're probably running in a mixed-media switched infrastructure (or maybe you're not - hence the problems :) ). If you want to get fancy you can buy span or rspan capable switches which will let you mirror traffic from individual ports or Vlans to a single management station port (in which case you can just use a desktop).

This should go withot saying, but those packet captures will be useless unless you know WHERE each mac address is on the network. That said:

1) maintain reliable L1/L2/L3 mappings
2) Tag both ends of long cables and make sure all wallports are numbered, and
3) beat the shit out of anyone who brings personal equipment in and plugs it in. It screws up your records and is probably less secure.

Yes, they need to by physically located on the same network as you.

Only thing is, the physical layer here is a broadcast medium. Any receiver within range of your transmission is already physically inside your network, while the access controls you have in place (encryption, for example) keep them logically outside the network.

Unfortunately wireless security is trivial to break, especially if someone monitors the initial connection between you and your router (but this is still not necessary). So unless your machines are always gone or off, it is possible for someone to defeat all the access controls and use the router.

Alternately, yes, someone could schwack your router. Unless you have yet to change the default login & password, then this is less likely that someone (e.g.) simply breaking your encryption.

If this is really a concern for you, check out the SANS Reading Room wireless section at http://www.sans.org/rr/whitepapers/wireless/.

"Results showed that all of the computers faced some
form of Internet attack during the experiment, with a combined total of
305,955 attacks recorded; the largest number of those attacks targeted
the regular Windows SP1 machine. The computers were successfully
compromised a total of ten times over the fourteen-day experiment period
with the very first compromise occurring on the regular Windows XP SP1
machine in less than 4 minutes immediately after placing the computer
live on the Internet."

"Four out of the six computers used in this
experiment were not successfully compromised by an Internet attack:
Linspire (Linux), Macintosh OS X 10.3.5, Windows XP SP1 with ZoneAlarm,
and Windows XP SP2. The Linspire (Linux), Windows XP SP1 with ZoneAlarm
and Windows XP SP2 systems placed first, second and third respectively,
when measuring systems with the fewest number of Internet attacks. These
systems provided the best protection against attempts to compromise the
computer during the two week period with each receiving less than 0.50%
of the total 305,955 attacks."

There are some simple work-arounds to project yourself from this exploit.

From http://isc.sans.org/diary.php?storyid=920

Go to Tools -> Options. Select the Privacy Icon, and then the History tab. Set the number of days to save pages at 0. This will disable writing anything to history.dat as far as I can tell, and should nullify the exploit. Readers have confirmed that this workaround does prevent the buffer overflow. You can also change your privacy settings to delete personal info when you close Firefox.

Another workaround is to modify prefs.js while Firefox has not been started and put in the line:

user_pref("capability.policy.default.HTMLDocument. title.set","noAccess");

Lastly, you can also run the NoScript extension, found here. (Which I have not looked at in depth.) However, there are other ways of exploiting this where NoScript might not work.

Some users have reported being unable to reproduce this error. I will test more to try to establish what makes this work and not. So far it appears Mac users are not affected by this.

No, just a badly worded summary of the original storm center diary entry in which the ISC handler attributes the possible FAILURE of this bug to crash firefox to the McAfee software, which, in his mind, has some mystical power to optimise firefox's inefficient string parsing algorithm even when it's deactivated!

This bug is slightly lame, even as DOS -- There are no confirmed reports from half-or-more-brain-having people that it even crashes the browser in the first place. All it does is make the subsequent startups slow, especially noticable in slower machines.

See bug 319004 at bugzilla.mozilla.org.

Cheers,
Toby Haynes

Obligatory reference to Average PC survival time

A lot is happening with DNSSEC these days. It is being deployed in the ccTLD for Sweden: ".se" Check out

http://dnssec.nic.se/

Tutorial/howto: http://www.ripe.net/disi/dnssec_howto/

$ dig @bind.dnssec.se www.ripe.net +retry=1 +dnssec +multiline
and look for the "flags" to include "ad": ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

http://www.dnssec-deployment.org/
  Threat Analysis Of The Domain Name System
    IETF RFC 3833 http://www.rfc-archive.org/getrfc.php?rfc=3833

Cache poisoning, in the wild:
      http://isc.sans.org/presentations/dnspoisoning.php
      http://www.dnssec-deployment.org/epi.htm

http://www.dnssec.net/

The SANS Internet Storm Center has a counter on their home page showing how many visitors to their site are vulnerable to this particular problem. At this time, looks like it is 43%! (and I assume that people checking the site are more security concious then the average). Also see MSIE 0day exploit.

The SANS Internet Storm Center has a counter on their home page showing how many visitors to their site are vulnerable to this particular problem. At this time, looks like it is 43%! (and I assume that people checking the site are more security concious then the average). Also see MSIE 0day exploit.

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.

Nice to see, though, that the only Unix problems they talk about are misconfigurations. This isn't really accurate, but nice to see anyway.

the actual top 20 list can be found here: http://www.sans.org/top20

Some versions of Safari have been affected.

http://isc.sans.org/diary.php?date=2005-11-21
We have received reports that Safari suffers from a DOS condition, but I have not been able to replicate it with Safari running on 10.3 or 10.4 series OSX machines.

It's ok for Panther or Tiger, but looks like users of OSX 10.2 and below could fall victim.

When I read about this first thing this morning I fired off an email to SANS http://www.isc.sans.org/ and got a reply quite quickly.

According to F-Secure http://www.f-secure.com/weblog the Trojan doesn't currently work, and in fact rebooting rids the computer of the infection.

We have just analyzed the first malware (Breplibot.b) that is trying to hide on machines that have Sony DRM software installed. Luckily, the bot has a design flaw. If the Sony DRM rootkit is active (hiding) in the system during infection, the bot will not run at all. Moreover, the bot cannot survive a reboot because of a programming error. In any case, this is a very good example of why software should not use rootkit hiding techniques.

i was scanned from 216.128.227.73 (19 hits) and 24.42.129.18 (14 hits).
first tries a wget fron 195.224.174.18/nikon, 2. one from 24.224.174.18/listen
both are down.

a third tries to get 62.101.193.244/lupii from 64.246.0.38, but it's down, too.

"listen" is also tried from 24.224.2.174/listen

more info on it here: http://isc.sans.org/diary.php?storyid=823

Internet Storm Center has information about new variant reported by TrendMicro:
http://isc.sans.org/diary.php?storyid=829

and the description itself is at http://www.trendmicro.com/vinfo/virusencyclo/defau lt5.asp?VName=ELF_LUPPER.B&VSect=P

Date Sources Targets Records tcp %
2005-11-07 5 5 11 100
2005-11-06 24 5 363 4
2005-11-05 27 4 2581 0
2005-11-04 35 8 5848 0
2005-11-03 111 8 22525 0
2005-11-02 6 7 10 100
2005-11-01 10 9 34 100
2005-10-31 6 7 33 100
2005-10-30 7 6 15 100

a decent description can be found here http://isc.sans.org/diary.php?storyid=823

Symantec has a more coverage description page at http://securityresponse.symantec.com/avcenter/venc /data/linux.plupii.html including links to XML-RPC PHP1.x library vulnerabilities used by this malware. This worm is also known as Linux.Plupii and Linux/Lupper.A too. Internet Storm Center has a lot of technical information at their http://isc.sans.org/diary.php?storyid=823

Will the free version of Oracle be subject ot the same weak Oracle password encryption scheme that the commercial version is?

I've duplicated a number of techniques in the SANS article to make me leery of password security on my Oracle machines.

Links to information:
First report: http://isc.sans.org/diary.php?storyid=770
Infocon Yellow: http://isc.sans.org/diary.php?storyid=772
Intrusion Detection: http://isc.sans.org/diary.php?storyid=782
Tool: http://isc.sans.org/diary.php?storyid=791

Hope everyone is safe..

Links to information:
First report: http://isc.sans.org/diary.php?storyid=770
Infocon Yellow: http://isc.sans.org/diary.php?storyid=772
Intrusion Detection: http://isc.sans.org/diary.php?storyid=782
Tool: http://isc.sans.org/diary.php?storyid=791

Hope everyone is safe..

Links to information:
First report: http://isc.sans.org/diary.php?storyid=770
Infocon Yellow: http://isc.sans.org/diary.php?storyid=772
Intrusion Detection: http://isc.sans.org/diary.php?storyid=782
Tool: http://isc.sans.org/diary.php?storyid=791

Hope everyone is safe..