Re: How to show messagebox in other computer in a network?
- From: Joseph M. Newcomer <newcomer@xxxxxxxxxxxx>
- Date: Wed, 24 Sep 2008 21:01:22 -0400
IRC is definitely vulnerable and I wouldn't trust it as far as I could throw a mainframe.
IM in every incarnation I know of is vulnerable. Don't touch them. They are a security
hole large enough to drive a freight train through. Sideways.
I have no idea what you mean by 'net send'. If you mean the TCP/IP send function, then
understand that programs like IM and messenger and such use TCP/IP at the lowest level,
but the security holes come not from the use of TCP/IP but by how the data is interpreted.
For example, if I write a program that will accept an arbitrary piece of code and just run
it without any security at all, it doesn't matter if I'm using TCP/IP or punched cards to
deliver the content; the fact that the content is executed is what makes it dangerous.
Oops. I just described VBScript, JavaScript, ActiveX, and I think every form of IM, IRC,
etc. that currently exist.
Don't confuse the transport layer (TCP/IP) with the application layer (IE, which takes the
data, declares it to be executable code, and runs it without limitation)
Mailslots only work within a single Windows domain because they are securable and require
validating the connection against the domain controller database.
A "maislot client" opens a file called
\\.\mailslot\yournamehere
and does a WriteFile to it. Thus, the program that wants to broadcast the fact that the
database has changed (your "server" app) is a mailslot *client* app.
A program that wants to look for a message on a mailslot opens the file
\\*\mailslot\yournamehere
and it is designated as a "mailslot server" (your servers are clients and your clients are
servers. Who chose this naming convention?) It does ReadFile operations on the handle it
opens and if there is any data received, will tell you by completing the ReadFile (note
that asynchronous I/O is really important here). You can then use that information any
way you choose.
But you can accomplish the same thing by simply doing a Receive on a socket. So if your
server app has the IP address of the client, and it wants to Send a bunch-o-bytes to the
client, and the client does a Receive, you have the same effect as with a mailslot. The
difference is that mailslots more closely resemble a UDP protocol, which is hard to use
across routers and especially if the routers are going out to the general internet,
because UDP protocols on various boxes (most *especially* linux boxes) are full of
security holes and allow snarfing of files and other forms of system penetration, so most
sysadmins simply block *all* incoming UDP. For WAN service, TCP/IP is just about the only
rational way to handle the communication. UDP has interesting features like broadcast and
multicast, but nearly every downstream router discards UDP broadcast and multicast packets
(it is fairly recent that routers can be configured to treat the other end as a virtual
single LAN and forward these packets; it used to be you couldn't even broadcast/multicast
from the third floor lab to the fourth floor machines if there was a router in between;
now you can tell the router that such packets can be forwarded. But this *never* happens
on routers outside your control, so essentially it is unusable except within a single
company)
If you do not do anything really dumb like copy a message of arbitrary length into a
buffer on the stack of much smaller length, or really, really stupid, like take the bytes
and execute them, ***it's just data***. Therefore, it cannot cause any damage, because
you have total and complete control of the data, and only if you write something
colossally bad or buggy will there be any possible risk. If the server never does a
Receive from a TCP/IP socket, nobody can get into it, and if the clients validate the
packet integrity (e.g., a GUID at the front, a date which has to be > some epoch date and
< now for some value of now (e.g., system clock time in GMT + n minutes to handle clock
skew), and a checksum based on some private algorithm, it is impossible for someone to
spoof a packet, and so what if they do? It doesn't do anything, really, except cause the
client to decide to resynchronize (OK, if you have 10,000 clients and someone spoofs all
of them every couple minutes, you have a potential denial-of-service situation as
everybody floods the server, but this can be protected against also, if you really care)
Note that the holes in IM/IRC/etc are caused by doing something really, really stupid,
which is to say, executing data as code without any kind of validation or limitation on
what it can do (note: certificates DO NOT solve this problem; they only give you the very
slight possibility of fixing blame, as if there was anything you could do about it after
the fact).
Bits are just bits until you do something with them.
joe
On Wed, 24 Sep 2008 17:05:01 -0700, Landon <Landon@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
I have read about MailSlots but I don't really understand about it. Is thereJoseph M. Newcomer [MVP]
any other method to solve this?
I thought if we have chat over mIRC or Yahoo Messenger, they are very risky
of virus? Or malware?
Does not net send use the same way as messenger does?
Thank you.
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.
- References:
- How to show messagebox in other computer in a network?
- From: Landon
- Re: How to show messagebox in other computer in a network?
- From: patrick
- Re: How to show messagebox in other computer in a network?
- From: Landon
- Re: How to show messagebox in other computer in a network?
- From: Joseph M . Newcomer
- Re: How to show messagebox in other computer in a network?
- From: Landon
- How to show messagebox in other computer in a network?
- Prev by Date: Re: Where's my Classwizard function Override capability ???
- Next by Date: Re: Is DAO going away?
- Previous by thread: Re: How to show messagebox in other computer in a network?
- Next by thread: How to display messages to the user during long processes!!
- Index(es):
Relevant Pages
|
