You can download PowerShell from here
Wednesday, November 23, 2011
You can download PowerShell from here
(svn status --no-ignore) -match '^\?' -replace '^\?\s+' | rm
Thursday, October 20, 2011
new Version("9.1") == new Version("126.96.36.199") // FALSE
What’s more weird is that this expression below is true!
new Version("9.1") < new Version("188.8.131.52") // TRUE!And that’s because unspecified components of the version are set to –1. In this case the build and revision for the Version on the left-hand side is –1.
So if you plan to use short-form versions like “9.1” you have to be careful when comparing it with full versions of the form “9.1.3”. This is specially important when one of the versions is constructed dynamically (user input or by querying some database).
Wednesday, September 7, 2011
In the last post I stated that a Sybase ‘login’ is mapped to a ‘database user’. In this post, I’ll elaborate on it further and introduce the concept of an ‘alias’.
One ‘login’ can be mapped to only one ‘database user’ in the given database. Obviously, at the server-level one ‘login’ can, and generally is mapped to many database users in different databases. For example, the ‘sa’ login is mapped to ‘dbo’ users in all databases. But how about the relationship in the other direction i.e. from ‘database user’ to a ‘login’?
Each ‘database user’ is also associated with one ‘login’ – except when there exists an ‘alias’. It is possible for two or more logins to be mapped to the same ‘database user’ by creating an ‘alias’. This allows both the logins to act as the same ‘database user’. This is typically done to allow multiple logins to act as database owners (i.e. user ‘dbo’). For example, as I mentioned earlier, ‘sa’ is always mapped to the ‘dbo’ user. If you wish to make someone else, lets say, ‘president’ login act as the ‘dbo’ database user, you create an alias
sp_addalias ‘president’, ‘dbo’
This would make both ‘sa’ and ‘president’ act as ‘dbo’. Note that you can have many aliases for a given ‘login’. You could very well also alias ‘vice_president’ to ‘sa’
sp_addalias ‘vice_president’, ‘dbo’
Even though multiple logins now act as the same ‘database user’, their activity can still be audited individually. This would not be possible if you simply gave the password for ‘sa’ login to everyone who you wish to make ‘dbo’, for example.
Tuesday, September 6, 2011
Logins - A ’login’ gives you access to the instance and is a server-level concept. You can add a ‘login’ using
sp_addlogin ‘login_name’, ‘password’
This adds an entry to the ‘master.dbo.syslogins’ table. Although a ‘login’ gives you access to the instance, to get access to a particular database, it must be mapped to an existing ‘database user’.
Database Users - Each database maintains its own set of database users. When creating a ‘database user’, the associated ‘login’ has to be supplied – like this
sp_adduser ‘login_name’, ‘database_user’
This adds an entry to the ‘<database_name>.dbo.sysusers’ table. Here the ‘login_name’ is mapped to ‘database_user’. Now, one thing to note is that one may add a ‘login’ but never map it to any particular ‘database user’ – what happens then is a little tricky and depends on the existence of a special user called ‘guest’.
Special ‘guest’ - If an explicit mapping does not exist between the ‘login’ and any of the existing database users, then the ‘login’ is implicitly mapped to the special ‘guest’ user, if one exists. If the 'guest’ user does not exist, the ‘login’ is denied access to the database. One can easily add the ‘guest’ user if it does not exist by using
When creating new database (using ‘create database’ for example), the ‘model’ database gets used as a template. In the versions of Sybase (12.5, 15, 15.5 on Linux/Windows) I played with I did not see the user ‘guest’ defined in the ‘model’ database. So the new databases based on ‘model’ will also not have the ‘guest’ user by default.
Monday, September 5, 2011
- “dmg” disk images for Lion and Snow Leopard. These contain pkg installers for use with the Mac OS X Installer. This is the simplest installation procedure that most users should follow after meeting the requirements listed below. An installer forLeopard, as a legacy platform, is also available.
Before installing enable the root user and install Xcode from the AppStore (on Lion) or Apple dev connection website (Snow Leopard/Leopard). You would need X11 as well for ports that depend on it. Use the package installer and then simply run this to update to the latest of MacPorts
sudo port -v selfupdate
Now, if you know the program you want to install is supported by MacPorts, like rsync for example, all you do to install it is
sudo port install rsync
Sunday, September 4, 2011
2. Click the padlock icon on the bottom left corner and enter your Administrator login credentials to unlock the application
3. In the Edit menu, select Enable Root User
Again from the Edit menu, select Change Root Password. A dialog window will apear prompting you to enter a root password
Wednesday, August 24, 2011
There is some flaw in the way Oracle handles user authentication. The authentication process seems to involve an initial TNS CONNECT from the client to which the server responds with an ACCEPT assuming correct server IP and port (1521 is the default LISTENER port) and SID/service name is specified. After which is negotiation of security services and exchange of a couple more packets. At one point, the client seems to send a login packet with username to which the server responds with a key (AUTH_SSKEY) indicating that some sort of a session initiation has begun. This is done whether the username specified in the packet is valid or not. If the client then abruptly terminates the connection as soon as the session key packet is received, the database seems to still keep track of that session internally. On Oracle 10g, sending such multiple login packets with invalid/arbitrary usernames and abruptly terminating connections after the AUTH_SSKEY is received, will very soon exhaust the 'maximum concurrent allowed sessions' limit and thus cause a DoS for other users. On Oracle 9i R2, I could get same results, but the login packet needs a valid username, because in 9i R2 the session key is only generated for valid users. Nevertheless, one can always use known usernames like 'sys', 'dbsnmp' etc
Oracle later confirmed this to be an issue in 11gR1 as well. To resolve the issue, Oracle enhanced the INBOUND_CONNECT_TIMEOUT configuration parameter in CPU April 2009. This parameter allows one to specify a timeout value in seconds to wait until the initiated login process is completed. So, using a small enough value for this parameter, an attacker will not be able to create too many such half-open logon sessions in order to cause the DoS. The default timeout is 60 sec, but it should be less IMHO, although it would really depend on many factors specific to each setup.
New error codes ORA-3135 and ORA-3136 were also added to indicate when the timeout is exceeded, in addition to the existing codes.
Rights to this research belong to my company Application Security, Inc.
Wednesday, August 3, 2011
If the indirect grant comes via a role, then revoke doesn't do anything (actually throws an error), but if the grant comes from the group to which the user belongs, then the user would be denied the privilege. Everyone else belonging to the group would continue to have the privilege except this user. A row is added to the sysprotects table to this effect. Also note it should be noted that this applies to object privileges only - revoking an indirectly granted system privilege (either via role or group) does not have any effect.
Also, its worth nothing here that role privileges trump any privilege grants and revokes at the group or direct user level.
To explain this by an example, lets assume user user1 belongs to group group1 and is also granted a role role1.
grant select on table table1 to group1
This gives user1 a select privilege on table1 via group group1.
revoke select on table1 from user1
This denies user1 select on table1
grant select on table1 to role1
This gives the select privilege back to user1 because the role privilege trumps any group and user level grants/revokes
Thursday, July 14, 2011
And when you revoked DBADM, these guys would still linger on! In 9.7 this changes - granting DBADM still gives you all these authorities ..but implicitly. You will not see them in the system catalog SYSCAT.DBAUTH view being granted. Nevertheless you will have them. And, naturally, when you revoke DBADM, they will be gone along with DBADM - just the way it should have always been..
1. ability to GRANT/REVOKE *any* database authority (except SECADM, which it never had)
2. ability to GRANT/REVOKE *any* privilege on *any* database object
This again is a significant step towards achieving separation of duties between the 'security administrator' and the 'database administrator'. A new authority 'Access Control authority' (ACCESSCTRL) was introduced to hold these privileges. By default, when DBADM is granted, ACCESSCTRL is also granted, but one can now choose to not do so by using
GRANT DBADM WITHOUT ACCESSCTRL
One thing to keep in mind is when DBADM is revoked, DATAACCESS and ACCESSCTRL (if granted by default) are NOT automatically revoked.
Wednesday, July 6, 2011
Another authority called DATAACCESS was introduced which does have implicit access to data. When granting someone DBADM, the default is still to grant DATAACCESS, but this can be changed using
GRANT DBADM WITHOUT DATAACCESS
A new 'access control' authority (ACCESSCTRL) is introduced in 9.7 which grants one the ability to grant/revoke *all* database authorities and *all* privileges on *all* objects! This new authority is implicitly included in the SECADM authority.
Tuesday, June 21, 2011
Something I just noticed is that in 9.7, the SYSADM (system administrator) authority no longer gets an implicit DBADM (database administrator) authority as it did in 9.1 and 9.5! It means that the SYSADM will no longer have access to any data in the database (unless it is the creator of the database as well, in which case DBADM is automatically granted)
Whats more.. the ability to grant/revoke DBADM and SECADM (security admin) no longer stays with SYSADM. And it only makes sense from point of view of 'separation of duties'