4. AmigaOS online as a server
4.0 Suitability
4.0.1 Finding out what is running
4.0.2 Closing ports
4.0.3 Never go online with...
4.1 Stacks
4.1.1 AmiTCP
4.1.2 Miami
4.1.3 Roadshow
4.1.4 UAE and bsdsocket emulation
4.2 Apache
4.2.1. PHP
4.2.2. MySQL client
4.2.3. SQLITE
4.3 Black Widow
4.4 SAMBA

4. AmigaOS online as a server

4.0 Suitability

AmigaOS can be used as a server and is suitable for such so long as the the designer of the server application and the systems administrator are aware that it has no internal security model.

If you are new to computing and want to put your Amiga on an internal network without wireless LAN then you may want to experiment here. If you want to put your Amiga in a DMZ, or on the internet directly then the general advice is DON'T RUN IT AS A SERVER.

A lot of the servers that you could run on the Amiga are hasty ports from the UNIX world ( or more precisely the Open Source world that writes for UNIX like operating systems ). This means that a lot of the UNIX assumptions ( like secured processes and filesystems ) that break under AmigaOS won't have been considered during the porting of the application.

Even applications that are written for AmigaOS often don't think through the consequences. Especially when it is one server used with a plugin that might expose a vulnerability ( for example: Apache, install PHP ) in the underlying Amiga architecture.

4.0.1 Finding out what is running

There are two places to look for this. Firstly in your s:startup-sequence, s:user-startup and WBStartup drawer for applications that offer internet services. If you don't know what the vulnerability status of the application is: remove entries that would automatically load it.

The second place to look is using the TCP/IP stack itself. The best means is to get it to show what open ports have items listening on them. Generally such servers will have a connection waiting in LISTEN or ACCEPT status.

Find out the equivalent of netstat -an is for each stack and post it here with sample output

Notice there are also other connections reported at strange port numbers? Don't worry, these are most likely to be outbound connections where your machine is a client.

4.0.2 Closing ports

It is possible with some TCP/IP stacks to close a port that a server would otherwise use ( this is a basic firewall methodology ) so that even if a server thinks it is listening on it, it can't. It might mean that when a server starts up it cannot work correctly in which case it will terminate and you can at least see what is listening on that port!

4.0.3 Never go online with

SAMBA running in network share mode ( where you are sharing out a drive or drawer on your Amiga to a network ). Vulnerabilities are found frequently in SMB and if you do go onto the internet with it you can expect your computer to spend at least part of its time processing enquiries about what SAMBA services are available. It is either insecure or wasteful.

A VNC server running allowing your Amiga to be remote controlled.

3. AmigaOS online as a client
3.0 Suitability
3.1 TCP/IP stacks
3.1.1. AmiTCP
3.1.2. Miami
3.1.3. Roadshow

3 AmigaOS online as a client

3.0 Suitability

Is AmigaOS suitable as a client? One of the main problems with AmigaOS being used as a network client isn't the OS itself but the version of the protocol or software that runs on it. A lot of these are backlevel or have been undertested.

You can use "old" applications like FTP, HTTP and TELNET on your local network if you like but you need to be aware of a few things:

A lot of the protocols that were designed for these applications were written in a more innocent time. They pass data in plain text ( ISO codepage at best ) and this means that they can be snooped on at the clients network or the servers network by a hostile third party. Because of this when you fill out a password and send it over one of these protocols it is like sending out a letter with the private contents on the outside - great so long as no one reads it on its way!

Client issues are closer to the general client issues that we encounter on all other operating systems, but there still is the flaw in that we can't prevent or limit a bad client application from screwing up your system unlike on Operating Systems that support security credentials.

Even on your home or business network you shouldn't consider yourself safe, especially if you use any wireless devices. You need to assume that someone may get into your home network at some point and you don't really want them to sniff out your passwords, bank details or even family photographs showing your children, your car registration plate or your house number.

Consider use secure alternatives, even if they have some flaws because they can act as a deterrant or delay.

At the end of this FAQ is a table which shows which clients and servers are rated for use in varying scenarios.

The client ones are:

AA -HOMESINGLE - A home user connected to the internet directly with no other computer on the local network.

AB - HOMENETWORK - A home user connected to the internet directly whom is using software based network connection sharing with one other computer on the local network.

AC - HOMESINGLEFIREWALL - As HOMESINGLE but behind a consumer firewall.

AD - HOMENETWORKGATEWAYFIREWALL - As HOMESINGLE but sharing and consumer firewall device are the same ( not the computer ).

AW - HOMEWIRELESS - Any A? scenario with a wireless device.

We strongly recommend reading up information on how to secure your wireless traffic properly no matter if you are in an urban or rural area. If you can't secure it with your device, throw it away or invest time in setting up a Virtual Private Network ( not covered in this FAQ ) to resolve some of the issues.

1.3 Data privacy

Information on your machine that you might fill out for just one site could be used on another. A recent attack allowed the contents of a clipboard to be used on Internet Explorer and that be sent to a remote site. Cookies are another long standing bone of contention for users but so are automatic form fillouts ( the information is held somewhere on your system ) for userids and passwords. Simpler privacy exposures can include Spyware ( that deliberately tracks usage patterns and reports them to a remote location ) or something just as simple as something that tracks your search strings and suggests alternatives.


1.4 General

The most important advice is to identify what type of risks you are currently exposed to and keep an eye on the security alerts that come around for that software. This cannot be under-emphasised because your typical cracker ( or the more clueless version who just uses existing scripts known dismissively as a ?script-kiddie? ) will be reading these alerts too and be waiting to expose your computer if they can.

Don't get overly paranoid if you can help it, don't let it suck out all enjoyment of using your Amiga online or offline but just be very aware that if someone finds they can do something unpleasant to someone else online they are going to do it.

AmigaOS Security FAQ

Revision: 0.0.2

Dated: 2nd December 2006

New advisories since previous revision:
Exploits N/A
Vulnerability N/A
Warnings N/A

1.General security concepts
1.0 Daemon attacks
1.1 Stack attacks
1.2 Trojan/Malware
1.3 General
2. AmigaOS limitations
2.0 Tasks, Processes, Signals and Messages
2.1 Permission bits
2.2 Paths
2.3 Functions and vectors
2.4 Virus attacks
2.5 Scripting
2.6 Servers, macros and automation
3. AmigaOS online as a client
3.0 TCP/IP stacks
3.0.1. AmiTCP
3.0.2. Miami
3.1 Web Browsers
3.1.1. Aweb
3.1.2. Ibrowse
3.1.3. Voyager
3.2 IRC
3.2.1. AmIRC
3.2.2. WookieChat
3.3 Email
3.3.1. YAM
3.3.2. SimpleMail
3.4 Remote shells
3.4.1. Telnet
3.4.2. Amtelnet
3.4.3. SSHv1
3.5 Remote file transfer
3.5.1. ftp
3.5.2. sftp
3.6 File sharing
3.6.1. SAMBA
4. AmigaOS online as a server
4.0 Suitability
4.1 Apache
4.1.1. PHP
4.1.2. MySQL client
4.1.3. SQLITE
4.2 Black Widow
4.3 SAMBA



1 General Security Concepts

Whenever you go online you will end up announcing your presence to the world. By doing this you are guaranteed that someone will try to test your connection to find ways in to do awful things at least once in your online lifetime. In fact the BBC honeypot experiment, although it had it's flaws, claimed it was hit by a potential security assault every 15 minutes.

http://news.bbc.co.uk/2/hi/technology/5414502.stm

( source BBC )

1.0 Daemon attacks

If you are running something on your machine that can be used by another computer on the internet then it is guaranteed to be found. If there is a known exploit for this then it is guaranteed to be exploited: it is only a matter of time. If there isn't a known exploit, but it actually does have a flaw that is unknown as of yet then someone will find it given motivation and time and you will be vulnerable.

By hiding behind what is known as a ?firewall?...

http://en.wikipedia.org/wiki/Firewall_%28networking%29

( source Wikipedia )

... you can mitigate the risk somewhat. By not running any of these types of programs, normally known as ?daemons?...

http://en.wikipedia.org/wiki/Daemon_%28computer_software%29

( source: Wikipedia )

...you can mitigate the risk even further. However it is still possible you can be subject to attack:

1.1 Stack attacks

TCP/IP stacks are assumed to be invulnerable, that is until the next flaw is found. The majority of flaws that have been discovered cause little more than a disconnect for the user, or tying down of system resources ( overloading ). Such attacks are most definitely handled by placing a firewall between you and the internet ? at least it makes it the firewalls problem.

1.2 Trojan, malware attacks

Trojan attacks are now a coverall term for attacks by which something gets onto your computer through your own volition. This can vary from accessing a web site and something on it does something to your machine ( as simple as a hang ? or launches off some program you have configured to handle a datatype which has its own bug ) or maybe you have mounted some network device that allows through lack of thought on the developers part that allows a script to be run that causes damage or maybe you just downloaded a bit of software that gives up some control of your machine to a cracker every time you connect to the network.

To handle these you should consider permitting some level of outbound firewall protection so that you are always aware of what is accessing the internet other than something you have initiated. But really, here, you need to be vigilant. If there are scanners available for your version of the Amiga Operating System you need to use them and keep them up to date.

1.3 General

The most important advice is to identify what type of risks you are currently exposed to and keep an eye on the security alerts that come around for that software. This cannot be under-emphasised because your typical cracker ( or the more clueless version who just uses existing scripts known dismissively as a ?script-kiddie? ) will be reading these alerts too and be waiting to expose your computer if they can.

Don't get overly paranoid if you can help it, don't let it suck out all enjoyment of using your Amiga online or offline but just be very aware that if someone finds they can do something unpleasant to someone else online they are going to do it.

2. AmigaOS limitations

AmigaOS has absolutely no security model beyond the ability to make files write protected ( 2.1 ). Bizzarely this does not make it entirely insecure because if you use it how it is designed and take precautions it can provide you a reasonable level of protection from attacks. We will discover more about how to do this in the FAQ.

2.0 Tasks, Processes, Signals and Messages

Any task can access the memory of another task in every revision up to, and including, AmigaOS 4.0. References to memory is habitually passed between running tasks and individual tasks are not assigned any security credential. Any task can remove another task from running in the execution list, signal another task to stop and to send messages to device drivers, windows, screens and other service processes.

Is this still true in Amiga OS 4.0?

2.1 Permission bits

Files can be write protected, read protected, delete protected and execute protected. However, any task can unset this if it so wishes. There are no security credentials for users, groups or ephemeral groups on the filesystem. Even if there where, there is no way of telling which task or process has a credential that can be compared with the filesystem credential to deny or allow access.

What about PFS? SFS?

2.2 Paths

Library and binary paths can be added to and removed from by anyone and if something is in the path it can be executed by any DOS process or shell. All paths are set globally as are assigns and library paths. What you do in one place has an effect on the entire operating system.

2.3 Functions and vectors

AmigaOS was traditionally attacked by "patching" vectors. AmigaOS in the Exec library allows you to override functions and methods to point to a different implementation. While this is useful for creating extensions and plugins and extending function it can also be used to inject trojan code, code that tracks personal information and change the behaviour of the operating system without the user being informed. There is no built in protection for this and even Exec methods and functions can be patched to target any other bit of code.

2.4 Virus attacks

Typical virus attack patterns here - bootblock, vector patches, etc.

2.5 Scripting

AREXX issues here, why it might be a good idea to disable AREXX unless you are really using it.

2.6 Servers, macros and automation

Theoretical exploitation of the system - probably too close to 2.5 to have its sown section

1. Trojan horses writen for AmigaOS (PPC or m68 CPU) ?
Never heard from one.

2. Daemon
Amiga is not Unix there are no daemons to be usesd.

Are you running any daemons? It could be valid but you have a PPC cpu which is not as popular as the x86. Even if you are using an exploit you should know the offsets where to jump which is different in every OS. And I'm not 100% sure, on OS4 it would work.

Quote:

3. Snooping and fishing for data. By not using the right level of security on your clients ( e.g. using telnet rather than SSL based clients ) they get hold of passwords and usernames just by listening in and seeing the raw plain text data passing.

It's a user related problem.