Hacker News Reader

Comment by zero_one_one | Hacker News Reader

There's a lot of posts mentioning that a scan shouldn't cause any trouble, however there's no way of knowing how the services are configured on the other end, or how they are set up to respond to certain packet types, or how the server will respond to certain data within those packets if said data does not conform to expected lengths etc. A lot of assumptions are made that non-conforming data will be ignored in a closed proprietary system, and that the system will handle all packets across all protocols gracefully. Anyone who says sending packets to a port running an unknown service (or implementation of said service) can't cause any issues with the service is throwing quite a wide net. Running a port scan or trying to interface with any of the systems on an aircraft while it's in flight without knowing how the systems operate or interact with each other is incredibly irresponsible, if not downright stupid.

View on HN

Irresponsible and stupid perhaps, but a lot of exaggeration here too.

I'd say the absolute worst case scenario is that the IFE crashes and must be restarted. Not a great result but not a plane crash and not a 10h flight without IFE either.

I'm not sure that there's any exaggeration in my post - I didn't mention any overblown outcomes that could result from these sort of actions, purely the considerations that weren't taken into account before the action was taken. I may not be seeing the wood for the trees though - it's been one of those days at work today! :)

Oh I didn't mean your post in particular containing exaggerations, more that there is generally a lot of talk here insinuating plane crashes or other catastrophic side effects coming from port scans.

The other almost-catastrophic outcome is apparently that the IFE system would not just crash, but be bricked in a state where it couldn't be restarted. Not impossible, but not likely either.

People switch seats in planes without asking the staff. That's also irresponsible and dangerous, and the worst case scenario is a crash. This is about the same level of risk if you ask me.

I remember about 20 years ago, you could crash any Windows computer you had the IP address of by sending a particularly crafted package to a certain port. Oh, those were the days.

Port 139, maybe?

http://insecure.org/sploits/windows.OOB.DOS.html

Also, ping of death:

http://insecure.org/sploits/ping-o-death.html

Ah, SQL Slammer... Those were the days indeed! :-)

https://en.m.wikipedia.org/wiki/SQL_Slammer

I think you're reading that incorrectly. The way I have interpreted those posts (including my own) is to say that if nmap can crash your software you should a) know that and b) not release it.

In 2017, you absolutely have a reasonable expectation that network systems are safe to nmap. You might be wrong, but that's a completely reasonable assumption.

I agree with you, that the expectation is reasonable, however in the real world this is not always the case. I totally agree that the systems should be tested for this, and if not they shouldn't be in a live environment.

However I draw the line when an unauthorized actor accesses a live system to prove a point, rather than going through proper procedures with absolutely no knowledge of the potential outcomes of his or her actions. This isn't white hat by any stretch of the imagination, and is incredibly reckless.

Reply on news.ycombinator.com