Linked by Thom Holwerda on Fri 5th Jan 2007 20:11 UTC, submitted by sogabe
Zeta MauriceK writes about security in the ZETA operating system. Apparently magnussoft, sole distributor of ZETA, makes security claims [on the German version] that with ZETA "it is not possible to examine a system from the outside without notifying the user due to the architecture of this software." MauriceK seems to think differently, and even gives examples on how code can be executed without the user's knowledge in ZETA. In related news, BeUnited is no more. Instant update: the discussion concerning security just made its appearance on the Haiku m-l.
Thread beginning with comment 198854
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Lol
by rayiner on Fri 5th Jan 2007 23:10 UTC in reply to "Lol"
rayiner
Member since:
2005-07-06

That's a point afterall. Even at the height of BeOS's popularity, I can't recall ever hearing of a BeOS virus.

Reply Parent Score: 4

RE[2]: Lol
by looncraz on Sat 6th Jan 2007 01:27 in reply to "RE: Lol"
looncraz Member since:
2005-07-24

One virus, which was made incompatible with the introduction of in-kernel networking ( BONE ).

Zeta uses a fixed-up revision BONE from all appearances, which was more secured. BONE is basically a source-less port if the BSD networking stack, which is known to be more or less secured by design.

The net_server BeOS revisions had a fatal flaw that was so easy to exploit, you would find yourself experiencing the side-effects after a lot of perfectly safe and normal network traffic. No hacking needed.. just ping a few hundred times to rid a dial-upped system, sending larger-sized packets for higher-end connections.

BONE, on the other hand, was never finished by Be, INC, and likely never had a security audit.. in fact I find this highly likely considering any BONE system can be ftp'd into and the user/pass of baron used to get in with full, un-monitor-ablem access. You could delete every file in every drive of the system, as the ftp root was the kernel's virtual root '/.'

Of course, Zeta should ship with all services off. Doing such could create a pretty secure system, and the internal methods for setting up those services for the network is surprisingly system-handled.

Basically, to start a network service on BONE, you would change the settings in a file, then send an alert to the kernel (through inetd?), the kernel would then process the file, obliging to the on/off settings (likely) without regard to who set them. However, in its 'released' state ( the latest Be BONE known, which is in Dano and early Zeta OS versions ), BONE would restart networking to have the file reloaded.

Restarting the networking stack to change a service is no biggy at all, unless your trying to hack the system and spent a couple hours getting into the system, and no find yourself completely out again because the network card was just shut off and back on, and the system may have even leased a new IP address ( either local or public ). That certainly adds in 'security' where other systems don't even try.

I decided to run a quick portscan over my network to my PhOS system and see what results we could get.

With xitami running for HTTP

$ portscanner -attackopen -violent 192.168.1.100
/bin/portscanner Version 1.2g
(C) JDG-looncraz, 2003
|
| Scanning 192.168.1.100
| Found Open Port: 80
| Attacking 192.168.1.100:80 ( 50 attacks )
| Scanning...
| Attack failed! Trying more violently...
| Scanning...
| Attack succeeded!
| The remote application serving 192.168.1.100:80
| should have been successfully hijacked.
| Continuing port scan...
| No More Open Ports!
$

As we can see, hacking in depends on the ports being open, which means some app is listening. It could be the kernel. ( Oh, one note, even though it says 'hijacked' the portscanner does not hijack yet, which is why it says 'should' :-) ).

Okay, now a run with no services on:

$ portscanner -attackopen -violent 192.168.1.100
/bin/portscanner Version 1.2g
(C) JDG-looncraz, 2003
|
| Scanning 192.168.1.100
| Scanning...
| Impossible to navigate IP address.
| Please make sure the IP address is correct, this
| is likely only to occur when the device at the
| IP address given has entered full lockdown or is
| running advanced firewall software.
$

A lot different.

Now, against Windows ( XP, default install, no firewall , no network services installed and only TCP/IP protocol )

$ portscanner -invadelist -mappedonly 192.168.1.104
/bin/portscanner Version 1.2g
(C) JDG-looncraz, 2003
|
| Scanning 192.168.1.104
| Found Unknown Windows, no firewall.
| Scanning...
| Found 12 Open ports!
| 4 Mapped for invasion.
| Remote Procedure Call, Alerter, Windows Update,
| MSN Messenger
| Print only, no invasion.
$

With the Windows Firewall on, you have to use a Windows Firewall exploit to get through. I haven't updated the app in years, so I haven't exploited any of them yet so that I can have the firewall on and use my network mass storage at the same time ( spanning storage needs across many machines silently ), but I am confident that the hardware firewalls I have do their trick :-)

Oh well, just a little FYI w/ my $0.02.

--The loon

Reply Parent Score: 2