amdphr3@kXP

welcome to MSFN lemon pie

*ditto* Welcome and enjoy ur stay .

How do you mean? Like on a network or with ur dsl connection? IT is possible to only allow certain ports with tcp/ip without a firewall, theres an option in the tcp/ip properties that allows you to specify what tcp ports you wish to allow on ur pc.

Have a good day dude

welcome to MSFN supergurl21

yeh true for some ppl it may not be an issue, isnt for me so i blocked em...

some more @nmhomeshow.com @slR.m78ot3v.com @news.com @u.petersonphotographics.com.hd @nmus.com @apple.com @purchasescheaper.com

welcome to MSFN, enjoy your stay

Here is a list of spam domains that you can block in ur hotmail accounts. I will update the list as i get more spam @wherewecandonuesr.com @v3H.77S.com @efc.ca @shellitbe.com @purchases-on-the-web.com @about.com @buy-online-4cheap.com @pbyxutmikol.com @0Yixr.jDDXXbBEM.com @geocities.com @friendlymail.net @cnn.com @getitlarger.biz @abraso.net @excite.com @google.ca @lycos.com

welcome to MSFN

Its a great idea, i despise the riaa and i hope they burn in hell

mine is f**kdariaa@kazaa

Microsoft Security Bulletin MS03-026 Print Buffer Overrun In RPC Interface Could Allow Code Execution (823980) Originally posted: July 16, 2003 Revised: July 21, 2003 Summary Who should read this bulletin: Users running Microsoft ® Windows ® Impact of vulnerability: Run code of attacker’s choice Maximum Severity Rating: Critical Recommendation: Systems administrators should apply the patch immediately End User Bulletin: An end user version of this bulletin is available at: http://www.microsoft.com/security/security...ns/ms03-026.asp. Affected Software: Microsoft Windows NT® 4.0 Microsoft Windows NT 4.0 Terminal Services Edition Microsoft Windows 2000 Microsoft Windows XP Microsoft Windows Server™ 2003 Not Affected Software: Microsoft Windows Millennium Edition Technical details Technical description: Microsoft originally released this bulletin and patch on July 16, 2003 to correct a security vulnerability in a Windows Distributed Component Object Model (DCOM) Remote Procedure Call (RPC) interface. The patch was and still is effective in eliminating the security vulnerability. However, the “mitigating factors” and “workarounds” discussions in the original security bulletin did not clearly identify all of the ports by which the vulnerability could potentially be exploited. We have updated this bulletin to more clearly enumerate the ports over which RPC services can be invoked, and to ensure that customers who have chosen to implement a workaround before installing the patch have the information that they need to protect their systems. Customers who have already installed the patch are protected from attempts to exploit this vulnerability, and need take no further action. Remote Procedure Call (RPC) is a protocol used by the Windows operating system. RPC provides an inter-process communication mechanism that allows a program running on one computer to seamlessly execute code on a remote system. The protocol itself is derived from the Open Software Foundation (OSF) RPC protocol, but with the addition of some Microsoft specific extensions. There is a vulnerability in the part of RPC that deals with message exchange over TCP/IP. The failure results because of incorrect handling of malformed messages. This particular vulnerability affects a Distributed Component Object Model (DCOM) interface with RPC, which listens on RPC enabled ports. This interface handles DCOM object activation requests that are sent by client machines to the server. An attacker who successfully exploited this vulnerability would be able to run code with Local System privileges on an affected system. The attacker would be able to take any action on the system, including installing programs, viewing changing or deleting data, or creating new accounts with full privileges. To exploit this vulnerability, an attacker would need to send a specially formed request to the remote computer on specific RPC ports. Mitigating factors: To exploit this vulnerability, the attacker would require the ability to send a specially crafted request to port 135, 139, or 445 or any other specifically configured RPC port on the remote machine. For intranet environments, these ports would normally be accessible, but for Internet connected machines, these would normally be blocked by a firewall. In the case where these ports are not blocked, or in an intranet configuration, the attacker would not require any additional privileges. Best practices recommend blocking all TCP/IP ports that are not actually being used, and most firewalls including the Windows Internet Connection Firewall (ICF) block those ports by default. For this reason, most machines attached to the Internet should have RPC over TCP or UDP blocked. RPC over UDP or TCP is not intended to be used in hostile environments such as the Internet. More robust protocols such as RPC over HTTP are provided for hostile environments. To learn more about securing RPC for client and server please refer to http://msdn.microsoft.com/library/default....t_or_server.asp. To learn more about the ports used by RPC, please refer to: http://www.microsoft.com/technet/prodtechn...rt4/tcpappc.asp Severity Rating: Windows NT 4.0 Critical Windows NT 4.0 Terminal Server Edition Critical Windows 2000 Critical Windows XP Critical Windows Server 2003 Critical The above assessment is based on the types of systems affected by the vulnerability, their typical deployment patterns, and the effect that exploiting the vulnerability would have on them. Vulnerability identifier: CAN-2003-0352 Tested Versions: Microsoft tested Windows Me, Windows NT 4.0, Windows NT 4.0 Terminal Services Edition, Windows 2000, Windows XP and Windows Server 2003, to assess whether they are affected by this vulnerability. Previous versions are no longer supported, and may or may not be affected by this vulnerability. Frequently asked questions Why have you revised this bulletin? Subsequent to the release of this bulletin Microsoft has been made aware that additional ports involving RPC can be used to exploit this vulnerability. Information regarding these additional ports has been added to the mitigating factors and the Workaround section of the bulletin. If I have installed the patch provided with the original bulletin, am I still protected? Yes. There has been no update to the patch itself, and the patch will still correct the vulnerability. This additional information is being provided to those customers who may require a temporary workaround until they can apply the patch. What’s the scope of the vulnerability? This is a buffer overrun vulnerability. An attacker who successfully exploited this vulnerability could gain complete control over a remote computer. This would give the attacker the ability to take any action on the server that they want. For example, and attacker could change Web pages, reformat the hard disk, or add new users to the local administrators group. To carry out such an attack, an attacker would require the ability to send a malformed message to the RPC service and thereby cause the target machine to fail in such a way that arbitrary code could be executed. What causes the vulnerability? The vulnerability results because the Windows RPC service does not properly check message inputs under certain circumstances. This particular failure affects an underlying Distributed Component Object Model (DCOM) interface, which listens on RPC enabled ports. By sending a malformed RPC message, an attacker could cause the RPC service on a machine to fail in such a way that arbitrary code could be executed. interface with RPC on the remote machine to fail in such a way that arbitrary code could be executed. What is DCOM? The Distributed Component Object Model (DCOM) is a protocol that enables software components to communicate directly over a network. Previously called "Network OLE," DCOM is designed for use across multiple network transports, including Internet protocols such as HTTP. More information about DCOM can be found at the following website: http://www.microsoft.com/com/tech/dcom.asp What is RPC (Remote Procedure Call)? Remote Procedure Call (RPC) is a protocol that a program can use to request a service from a program located on another computer in a network. RPC helps with interoperability because the program using RPC does not have to understand the network protocols that are supporting communication. In RPC, the requesting program is the client and the service-providing program is the server. What's wrong with Microsoft’s implementation of Remote Procedure Call (RPC)? There is a flaw in a part of RPC that deals with message exchange over TCP/IP. A failure results because of incorrect handling of malformed messages. This particular failure affects an underlying DCOM interface, which listens on TCP/IP port 135, and can be reached via ports 139 and 445. By sending a malformed RPC message, an attacker could cause the RPC service on a machine to fail in such a way that arbitrary code could be executed. Is this a flaw in the RPC Endpoint Mapper? No - The flaw actually occurs in a low level DCOM interface within the RPC process. The RPC endpoint mapper allows RPC clients to determine the port number currently assigned to a particular RPC service. An endpoint is a protocol port or named pipe on which the server application listens to for client remote procedure calls. Client/server applications can use either well-known or dynamic ports. Security Bulletin MS03-010 also involved RPC yet you could not fix that vulnerability on Windows NT 4.0. How were you able to fix this vulnerability on Windows NT 4.0? The flaw in this case lies in an underlying DCOM interface to RPC, and not the overall RPC implementation or the RPC Endpoint Mapper itself. As a result, it was possible to address this vulnerability in Windows NT 4.0 without needing to rearchitect significant portions of the Windows NT 4.0 operating system, as would have been required by a Windows NT 4.0 patch for security bulletin MS03-010. What could this vulnerability enable an attacker to do? An attacker who successfully exploited this vulnerability would be able to run code with Local System privileges on an affected system. The attacker would be able to take any action on the system, including installing programs, viewing changing or deleting data, or creating new accounts with full privileges. How could an attacker exploit this vulnerability? An attacker could seek to exploit this vulnerability by programming a machine that could communicate with a vulnerable server over RPC to send a specific kind of malformed RPC message. Receipt of such a message could cause the RPC service on the vulnerable machine to fail in such a way that it could execute arbitrary code. Who could exploit the vulnerability? Any user who could deliver a TCP request to an RPC interface to an affected computer could attempt to exploit the vulnerability. Because RPC requests are on by default in all versions of Windows, this in essence means that any user who could establish a connection with an affected computer could attempt to exploit the vulnerability. It could also be possible to access the affected component through another vector, such as one that would involve logging onto the system interactively or by using another application similar that passed parameters to the vulnerable component either locally or remotely. What does the patch do? The patch corrects the vulnerability by altering the DCOM interface to properly check the information passed to it. Workarounds Are there any workarounds that can be used to block exploitation of this vulnerability while I am testing or evaluating the patch? Yes. Although Microsoft urges all customers to apply the patch at the earliest possible opportunity, there are a number of workarounds that can be applied to help prevent the vector used to exploit this vulnerability in the interim. It should be noted that these workarounds should be considered temporary measures as they just help block paths of attack rather than correcting the underlying vulnerability. The following sections are intended to provide you with information to help protect your computer from attack. Each section describes the workarounds that you may want to use depending on your computer’s configuration. Each section describes the workarounds available depending on your required level of functionality. Block RPC interface ports at your firewall. Port 135 is used to initiate an RPC connection with a remote computer. In addition, there are other RPC interface ports that could be used by an attacker to remotely exploit this vulnerability. Blocking the following ports at the firewall will help prevent systems behind that firewall from being attacked by attempts to exploit this vulnerability: TCP/UDP Port 135 TCP/UDP Port 139 TCP/UDP Port 445 In addition, customers may have configured services or protocols that use RPC that might also be accessible from the Internet. Systems administrators are strongly encouraged to examine RPC ports that are exposed to the Internet and to either block these ports at their firewall, or apply the patch immediately. Internet Connection Firewall. If you are using the Internet Connection Firewall in Windows XP or Windows Server 2003 to protect your Internet connection, it will by default block inbound RPC traffic from the Internet. Disable DCOM on all affected machines When a computer is part of a network, the DCOM wire protocol enables COM objects on that computer to communicate with COM objects on other computers. You can disable DCOM for a particular computer to help protect against this vulnerability, but doing so will disable all communication between objects on that computer and objects on other computers. If you disable DCOM on a remote computer, you will not be able to remotely access that computer afterwards to reenable DCOM. To reenable DCOM, you will need physical access to that computer. To manually enable (or disable) DCOM for a computer: 1. Run Dcomcnfg.exe. If you are running Windows XP or Windows Server 2003 perform these additional steps: Click on the Component Services node under Console Root. Open the Computers sub-folder. For the local computer, right click on My Computer and choose Properties. For a remote computer, right click on the Computers folder and choose New then Computer. Enter the computer name. Right click on that computer name and choose Properties. 2. Choose the Default Properties tab. 3. Select (or clear) the Enable Distributed COM on this Computer check box. 4. If you will be setting more properties for the machine, click the Apply button to enable (or disable) DCOM. Otherwise, click OK to apply the changes and exit Dcomcnfg.exe. Patch availability Download locations for this patch Windows NT 4.0 Server Windows NT 4.0 Terminal Server Edition Windows 2000 Windows XP 32 bit Edition Windows XP 64 bit Edition Windows Server 2003 32 bit Edition Windows Server 2003 64 bit Edition Additional information about this patch Installation platforms: The Windows NT 4.0 patch can be installed on systems running Service Pack 6a. The Windows NT 4.0, Terminal Server Edition patch can be installed on systems running Windows NT 4.0, Terminal Server Edition Service Pack 6. The Windows 2000 patch can be installed on systems running Windows 2000 Service Pack 3, or Service Pack 4. The patch for Windows XP can be installed on systems running Windows XP Gold or Service Pack 1. The patch for Windows Server 2003 can be installed on systems running Windows Server 2003 Gold. Inclusion in future service packs: The fix for this issue will be included in Windows 2000 Service Pack 5, Windows XP Service Pack 2, and Windows Server 2003 Service Pack 1. Reboot needed: Yes. Patch can be uninstalled: Yes. Superseded patches: None. Verifying patch installation: Windows NT 4.0: To verify that the patch has been installed on the machine, confirm that all files listed in the file manifest in Knowledge Base article 823980 are present on the system. Windows NT 4.0 Terminal Server Edition: To verify that the patch has been installed on the machine, confirm that all files listed in the file manifest in Knowledge Base article 823980 are present on the system. Windows 2000: To verify that the patch has been installed on the machine, confirm that the following registry key has been created on the machine: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows 2000\SP5\KB823980. To verify the individual files, use the date/time and version information provided in the file manifest in Knowledge Base article 823980 are present on the system. Windows XP If installed on Windows XP Gold: To verify that the patch has been installed on the machine, confirm that the following registry key has been created on the machine: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows XP\SP1\KB823980 To verify the individual files, use the date/time and version information provided in the file manifest in Knowledge Base article 823980 are present on the system. If installed on Windows XP Service Pack 1: To verify that the patch has been installed on the machine, confirm that the following registry key has been created on the machine: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows XP\SP2\KB823980. To verify the individual files, use the date/time and version information provided in the file manifest in Knowledge Base article 823980 are present on the system. Windows Server 2003: To verify that the patch has been installed on the machine, confirm that the following registry key has been created on the machine: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Window Server 2003\SP1\KB823980. To verify the individual files, use the date/time and version information provided in the file manifest in Knowledge Base article 823980 are present on the system. Caveats: None Localization: Localized versions of this patch are available at the locations discussed in “Patch Availability”. Obtaining other security patches: Patches for other security issues are available from the following locations: Security patches are available from the Microsoft Download Center, and can be most easily found by doing a keyword search for "security_patch". Patches for consumer platforms are available from the WindowsUpdate web site Other information: Acknowledgments Microsoft thanks The Last Stage of Delirium Research Group for reporting this issue to us and working with us to protect customers. Support: Microsoft Knowledge Base article 823980 discusses this issue and will be available approximately 24 hours after the release of this bulletin. Knowledge Base articles can be found on the Microsoft Online Support web site. Technical support is available from Microsoft Product Support Services. There is no charge for support calls associated with security patches. Security Resources: The Microsoft TechNet Security Web Site provides additional information about security in Microsoft products. Disclaimer: The information provided in the Microsoft Knowledge Base is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply. Revisions: V1.0 (July 16, 2003): Bulletin Created. V1.1 (July 18, 2003): Mitigating factors and Workaround section updated to reflect additional ports. V1.2 (July 21, 2003): Added Windows XP gold patch verification registry key.

athlon

Computer parts, and also viruses cuz they are interesting

np

Dont mean to get off topic, but how on earth did u manage to obtain it from ur school? I dont know of any school that would lend the cd to anyone due to copyright laws...

yeh u wont b able to modify it whilst win2k3 is running, are u using fat32 or ntfs? If fat32, boot from a win9x cd and type attrib c:\boot.ini -r -a -s -h, c:\ being the letter of the partition that it is located then edit c:\boot.ini, c:\ also the letter of the partition. If NTFS, you should be able to boot from the win2k3 cd into setup, once at the first setup screen, enter the recovery console. You should be able to type attrib...etc there and then edit c:\boot.ini

roflmao!

Also make sure that you have netbios enabled in ur tcp/ip settings. This must be enabled in order for machines to be able to see each other/share resources etc.

optus 56k dialup

happy bday dude

late but anyways, happy b'day dudes! Hope yas had a good 1

me thinks that is a good idea. The RIAA = a$$holes. Little do they realise, before p2p, record sales were plummeting due to increasing music prices and cheaper cd burners. When napster began p2p, record sales have continued to increase due to people being able to preview tracks from an album, allowing them to make a decision on the cd's that they wish to purchase without wasting money on something they will only listen to once. Attacking p2p networks will only encourage people to rebel and copy more and more music, which is the case at the moment. They are as blind as they are dumb

welcome to MSFN, enjoy your stay