FAQ
Hey all,

I've been helping a developer work with a vendor in decyphering why their stinking Oracle client on Windohs doesn't work. One tool I found at Quest can monitor SQL calls from a Windows program that uses the Oracle Client. Very cool. But it got me to thinking...



More than a year ago, we had problems with a Perl::DBI program connecting to the Oracle DB using the WE8ISO8859P1 charset. It always failed the first time and secretly and automagically attempted and succeeded the connection a second time. I was able to verify this by using AUDIT in the DB, while running the program.



As I recall, an Oracle client trace showed the password sent as plaintext after the first failure. The fix was to upgrade Perl from 5.0 to 5.6 (or 5.8, I forget) which also necessitated a DBI upgrade (I forget what versions). At the time, the client was 8.0.5 and the server was 8.1.7.



Has anyone heard of this before? It seems to me that it wouldn't be too difficult to force the issue, causing the password to be sent plaintext. I don't know how big of a security deal this could be, but it piqued my curiosity.



TIA,

Rich



Rich Jesse System/Database Administrator
rich.jesse_at_quadtechworld.com QuadTech, Sussex, WI USA

----------------------------------------------------------------

Please see the official ORACLE-L FAQ: http://www.orafaq.com

To unsubscribe send email to: oracle-l-request_at_freelists.org
put 'unsubscribe' in the subject line.

Search Discussions

  • Jared.Still_at_radisys.com at Aug 6, 2004 at 3:36 pm

    More than a year ago, we had problems with a Perl::DBI program
    connecting to the Oracle DB using the WE8ISO8859P1 charset. It
    always failed the first time and secretly and automagically
    attempted and succeeded the connection a second time. I was able to
    verify this by using AUDIT in the DB, while running the program.

    From the fine manual:
    By setting the following values, you can require that the password used to
    verify a connection always be encrypted:
    Set the ORA_ENCRYPT_LOGIN environment variable to TRUE on the client
    machine.
    Set the DBLINK_ENCRYPT_LOGIN server initialization parameter to TRUE.
    If enabled at both the client and server, passwords will not be sent
    across the network "in the clear", but will be encrypted using a modified
    DES (Data Encryption Standard) algorithm.
    The DBLINK_ENCRYPT_LOGIN initialization parameter is used for connections
    between two Oracle servers (for example, when performing distributed
    queries). If you are connecting from a client, Oracle checks the
    ORA_ENCRYPT_LOGIN environment variable.
    Whenever you attempt to connect to a server using a password, Oracle
    encrypts the password before sending it to the server. If the connection
    fails and auditing is enabled, the failure is noted in the audit log.
    Oracle then checks the appropriate DBLINK_ENCRYPT_LOGIN or
    ORA_ENCRYPT_LOGIN value. If it set to FALSE, Oracle attempts the
    connection again using an unencrypted version of the password. If the
    connection is successful, the connection replaces the previous failure in
    the audit log, and the connection proceeds. To prevent malicious users
    from forcing Oracle to re-attempt a connection with an unencrypted version
    of the password, you must set the appropriate values to TRUE.

    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Jesse, Rich at Aug 6, 2004 at 4:01 pm
    How in the world did you find this? Even after I see the answer, what =
    did you search on to find it?

    I'm also wondering exactly how this is pulled off. I know a user can be =
    locked out of the registry. But if the user fires up a DOS window, sets =
    the ORA_ENCRYPT_LOGIN environment variable to FALSE, and fires up some =
    client program from that DOS window, does that client program's Oracle =
    connection (assuming it's a self-standing 32-bit) revert to the =
    ORA_ENCRYPT_LOGIN env var as it sits in the registry or as it was =
    redefined in the DOS window? For that matter, can a user even set an =
    env var if they are locked out of the registry? I'm not sure how this =
    mechanism works (or was designed to work) in Winders.

    Not that it particularly matters for us, as this particular client was =
    Unix and user's are locked out from shell access (and ftp, ssh, etc. to =
    be able to override their own .profile/.login/.bash_profile/etc), but =
    I'm curious.

    Thx, Jared!
    Rich

    -----Original Message-----
    Sent: Friday, August 06, 2004 3:40 PM
    Subject: Re: Oracle client security
    More than a year ago, we had problems with a Perl::DBI program=20
    connecting to the Oracle DB using the WE8ISO8859P1 charset. It=20
    always failed the first time and secretly and automagically=20
    attempted and succeeded the connection a second time. I was able to
    verify this by using AUDIT in the DB, while running the program.
    =20
    From the fine manual:
    By setting the following values, you can require that the password used =
    to=20
    verify a connection always be encrypted:=20
    Set the ORA_ENCRYPT_LOGIN environment variable to TRUE on the client=20
    machine.=20
    Set the DBLINK_ENCRYPT_LOGIN server initialization parameter to TRUE.=20
    If enabled at both the client and server, passwords will not be sent=20
    across the network "in the clear", but will be encrypted using a =
    modified=20
    DES (Data Encryption Standard) algorithm.=20
    The DBLINK_ENCRYPT_LOGIN initialization parameter is used for =
    connections=20
    between two Oracle servers (for example, when performing distributed=20
    queries). If you are connecting from a client, Oracle checks the=20
    ORA_ENCRYPT_LOGIN environment variable.=20
    Whenever you attempt to connect to a server using a password, Oracle=20
    encrypts the password before sending it to the server. If the connection =

    fails and auditing is enabled, the failure is noted in the audit log.=20
    Oracle then checks the appropriate DBLINK_ENCRYPT_LOGIN or=20
    ORA_ENCRYPT_LOGIN value. If it set to FALSE, Oracle attempts the=20
    connection again using an unencrypted version of the password. If the=20
    connection is successful, the connection replaces the previous failure =
    in=20
    the audit log, and the connection proceeds. To prevent malicious users=20
    from forcing Oracle to re-attempt a connection with an unencrypted =
    version=20
    of the password, you must set the appropriate values to TRUE.=20

    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Jared.Still_at_radisys.com at Aug 6, 2004 at 4:25 pm

    How in the world did you find this? Even after I see the answer, what =
    did you search on to find it?
    Well, I already knew it was there. :)
    I'm also wondering exactly how this is pulled off. I know a user can be =
    locked out of the registry. But if the user fires up a DOS window, sets =
    the ORA_ENCRYPT_LOGIN environment variable to FALSE, and fires up some =
    client program from that DOS window, does that client program's Oracle =
    connection (assuming it's a self-standing 32-bit) revert to the =
    ORA_ENCRYPT_LOGIN env var as it sits in the registry or as it was =
    redefined in the DOS window? For that matter, can a user even set an =
    env var if they are locked out of the registry? I'm not sure how this =
    mechanism works (or was designed to work) in Winders.
    I haven't played with it, or if I have, I don't recall the results.

    Jared

    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Alex Feinstein at Aug 7, 2004 at 10:35 pm
    Rich,

    Parameter ORA_ENCRYPT_LOGIN used only for client 7.1+ connecting to 7.0
    database.
    In all other cases its value irelevant.
    See note 271825.1

    Alex.

    Original Message -----
    From: "Jesse, Rich"
    To:
    Sent: Friday, August 06, 2004 2:05 PM
    Subject: RE: Oracle client security

    How in the world did you find this? Even after I see the answer, what =
    did you search on to find it?

    I'm also wondering exactly how this is pulled off. I know a user can be =
    locked out of the registry. But if the user fires up a DOS window, sets =
    the ORA_ENCRYPT_LOGIN environment variable to FALSE, and fires up some =
    client program from that DOS window, does that client program's Oracle =
    connection (assuming it's a self-standing 32-bit) revert to the =
    ORA_ENCRYPT_LOGIN env var as it sits in the registry or as it was =
    redefined in the DOS window? For that matter, can a user even set an =
    env var if they are locked out of the registry? I'm not sure how this =
    mechanism works (or was designed to work) in Winders.

    Not that it particularly matters for us, as this particular client was =
    Unix and user's are locked out from shell access (and ftp, ssh, etc. to =
    be able to override their own .profile/.login/.bash_profile/etc), but =
    I'm curious.

    Thx, Jared!
    Rich

    -----Original Message-----
    Sent: Friday, August 06, 2004 3:40 PM
    Subject: Re: Oracle client security
    More than a year ago, we had problems with a Perl::DBI program=20
    connecting to the Oracle DB using the WE8ISO8859P1 charset. It=20
    always failed the first time and secretly and automagically=20
    attempted and succeeded the connection a second time. I was able to
    verify this by using AUDIT in the DB, while running the program.
    =20
    From the fine manual:
    By setting the following values, you can require that the password used =
    to=20
    verify a connection always be encrypted:=20
    Set the ORA_ENCRYPT_LOGIN environment variable to TRUE on the client=20
    machine.=20
    Set the DBLINK_ENCRYPT_LOGIN server initialization parameter to TRUE.=20
    If enabled at both the client and server, passwords will not be sent=20
    across the network "in the clear", but will be encrypted using a =
    modified=20
    DES (Data Encryption Standard) algorithm.=20
    The DBLINK_ENCRYPT_LOGIN initialization parameter is used for =
    connections=20
    between two Oracle servers (for example, when performing distributed=20
    queries). If you are connecting from a client, Oracle checks the=20
    ORA_ENCRYPT_LOGIN environment variable.=20
    Whenever you attempt to connect to a server using a password, Oracle=20
    encrypts the password before sending it to the server. If the connection =

    fails and auditing is enabled, the failure is noted in the audit log.=20
    Oracle then checks the appropriate DBLINK_ENCRYPT_LOGIN or=20
    ORA_ENCRYPT_LOGIN value. If it set to FALSE, Oracle attempts the=20
    connection again using an unencrypted version of the password. If the=20
    connection is successful, the connection replaces the previous failure =
    in=20
    the audit log, and the connection proceeds. To prevent malicious users=20
    from forcing Oracle to re-attempt a connection with an unencrypted =
    version=20
    of the password, you must set the appropriate values to TRUE.=20

    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------

    ----------------------------------------------------------------
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    ----------------------------------------------------------------
    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.
    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Jared Still at Aug 8, 2004 at 9:59 am

    On Sat, 2004-08-07 at 20:33, Alex Feinstein wrote:
    Rich,

    Parameter ORA_ENCRYPT_LOGIN used only for client 7.1+ connecting to 7.0
    database.
    In all other cases its value irelevant.
    See note 271825.1
    This explains why the 'feature' exists, but the use
    of ORA_ENCRYPT_LOGIN is hardly irrelevant.

    For versions of Oracle client < 9i, setting ORA_ENCRYPT_LOGIN
    is still not a bad idea, as a failure to connect will still
    result in a password being sent in the clear.

    Jared

    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • MacGregor, Ian A. at Aug 6, 2004 at 5:23 pm
    Yes, but these parameters are obsolete as of 9i.

    -----Original Message-----
    From: Jared.Still_at_radisys.com
    Sent: Friday, August 06, 2004 1:40 PM
    To: oracle-l_at_freelists.org
    Subject: Re: Oracle client security
    More than a year ago, we had problems with a Perl::DBI program
    connecting to the Oracle DB using the WE8ISO8859P1 charset. It always
    failed the first time and secretly and automagically attempted and
    succeeded the connection a second time. I was able to verify this by
    using AUDIT in the DB, while running the program.

    From the fine manual:
    By setting the following values, you can require that the password used to verify a connection always be encrypted:
    Set the ORA_ENCRYPT_LOGIN environment variable to TRUE on the client machine.
    Set the DBLINK_ENCRYPT_LOGIN server initialization parameter to TRUE.
    If enabled at both the client and server, passwords will not be sent across the network "in the clear", but will be encrypted using a modified DES (Data Encryption Standard) algorithm.
    The DBLINK_ENCRYPT_LOGIN initialization parameter is used for connections between two Oracle servers (for example, when performing distributed queries). If you are connecting from a client, Oracle checks the ORA_ENCRYPT_LOGIN environment variable.
    Whenever you attempt to connect to a server using a password, Oracle encrypts the password before sending it to the server. If the connection fails and auditing is enabled, the failure is noted in the audit log.
    Oracle then checks the appropriate DBLINK_ENCRYPT_LOGIN or ORA_ENCRYPT_LOGIN value. If it set to FALSE, Oracle attempts the connection again using an unencrypted version of the password. If the connection is successful, the connection replaces the previous failure in the audit log, and the connection proceeds. To prevent malicious users from forcing Oracle to re-attempt a connection with an unencrypted version of the password, you must set the appropriate values to TRUE.

    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
    ----------------------------------------------------------------
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    ----------------------------------------------------------------
    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.
    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Jared.Still_at_radisys.com at Aug 6, 2004 at 6:00 pm

    oracle-l-bounce_at_freelists.org wrote on 08/06/2004 03:27:03 PM:
    Yes, but these parameters are obsolete as of 9i.
    True, though I did pull that from the 9.2.0 docs. It is apparently
    a documentation bug, as 9i supposedly always encrypts passwords
    and never sends them in the clear. Haven't tested it though.

    Jared

    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Pete Finnigan at Aug 8, 2004 at 2:21 am

    True, though I did pull that from the 9.2.0 docs. It is apparently
    a documentation bug, as 9i supposedly always encrypts passwords
    and never sends them in the clear. Haven't tested it though.

    Jared
    Hi Jared,

    The parameters are supposedly not used or rather ignored from 9iR2 (It
    could be 9iR1 as I have heard this for both versions) as all retries are
    encrypted by default. I tested this over a year ago when discussing it
    with Don Granaman who was involved in the CIS Oracle benchmark. We could
    not find a way to get a second try in clear text on 9i. This
    "functionality" the second try in clear text was added to allow
    connection to older databases that didn't support the encrypted password
    exchange (7.1 and down i believe).

    Rich, The way to secure the client then seems to be to ensure at least
    9iR1 or 9iR2 clients are used.

    Kind regards

    Pete

    --
    Pete Finnigan
    email:pete_at_petefinnigan.com
    Web site: http://www.petefinnigan.com - Oracle security audit specialists
    Book:Oracle security step-by-step Guide - see http://store.sans.org for details.

    ----------------------------------------------------------------
    Please see the official ORACLE-L FAQ: http://www.orafaq.com
    ----------------------------------------------------------------
    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.
    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------
  • Jesse, Rich at Aug 9, 2004 at 9:00 am
    Excellent! I'll file this under "Good Things To Know".

    And now I know The Rest Of The Story.

    Good day!

    Rich

    Rich Jesse System/Database Administrator
    rich.jesse_at_quadtechworld.com QuadTech, Sussex, WI USA

    -----Original Message-----
    Sent: Saturday, August 07, 2004 3:57 PM
    Subject: Re: Oracle client security
    True, though I did pull that from the 9.2.0 docs. It is apparently
    a documentation bug, as 9i supposedly always encrypts passwords
    and never sends them in the clear. Haven't tested it though.

    Jared
    Hi Jared,

    The parameters are supposedly not used or rather ignored from 9iR2 (It
    could be 9iR1 as I have heard this for both versions) as all retries are
    encrypted by default. I tested this over a year ago when discussing it
    with Don Granaman who was involved in the CIS Oracle benchmark. We could
    not find a way to get a second try in clear text on 9i. This
    "functionality" the second try in clear text was added to allow
    connection to older databases that didn't support the encrypted password
    exchange (7.1 and down i believe).

    Rich, The way to secure the client then seems to be to ensure at least
    9iR1 or 9iR2 clients are used.=20

    Kind regards

    Pete

    Please see the official ORACLE-L FAQ: http://www.orafaq.com

    To unsubscribe send email to: oracle-l-request_at_freelists.org
    put 'unsubscribe' in the subject line.

    --
    Archives are at http://www.freelists.org/archives/oracle-l/
    FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
    -----------------------------------------------------------------

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouporacle-l @
categoriesoracle
postedAug 6, '04 at 1:44p
activeAug 9, '04 at 9:00a
posts10
users6
websiteoracle.com

People

Translate

site design / logo © 2022 Grokbase