Friday, April 25, 2014

EXECUTE IMMEDIATE: SQL injection prevention / EXECUTE IMMEDIATE: Prevenção SQL injection

This article is written in Englsih and Portuguese (original version here)
Este artigo está escrito em Inglês e Português (versão original aqui)


English version
Recently I was requested to implement some stored procedures on a customer site. The request was urgent and I must admit I didn't pay enough attention. The procedures needed to accept some values that would be used inside some SQL statements. Basic best practices mandate that we must check all parameters and in such cases use prepared statements. These principles provide for better interaction with the calling layer and more important, help us avoid a classic and nasty security flaw called SQL injection.
The idea behind SQL injection is terribly simple and efficient: By supplying specially crafted parameters we explore the developer's mistake of not sanitizing those parameters and blindly use them to construct SQL statements. By doing so we may be able to change the meaning of those statements or eventually terminate them and include our own. A couple of examples:

  1. An authentication page uses the SQL statement:
    SELECT
        COUNT(*)
    FROM
        user_table
    WHERE
        user_name = $USER AND user_pass = '$PASS'
    

    and we supply these arguments:
    'john_doe'
    'dummy'' OR ( user_name = ''john_doe'' )'
    

  2. An online banking uses the SQL statement:
    UPDATE
        balance_account
    SET
        ammount = ammount - $VALUE
    WHERE
        account_number = $SOME_NUMBER
    

    and we supply these arguments:
    - 1000
    our_account_number
    

Well, after the procedures were created and some basic testing was done I had a bit more time to look at the code and I noticed I used the SQL instruction "EXECUTE IMMEDIATE..." where I was just concatenating some SQL with the provided arguments. Some of them were being slightly checked, but others were not checked at all. I was alarmed and ashamed by that piece of code and I decided to prove it was crappy... I tried to send weird parameters which included a semi-colon and a full statement following it. As an example consider something like:

CREATE PROCEDURE test_proc(table_name VARCHAR(20))
    EXECUTE IMMEDIATE "DROP TABLE " || table_name
END PROCEDURE;

And I tried to send "some_table;DROP DATABASE d"

(consider that some_table is an existent table name and "d" and existing database)
It raised error

26058: EXECUTE IMMEDIATE and PREPARE in SPL cannot allow multiple SQL statements

Which was a bit of a surprise. I tried other variations and they all failed.
The error description is clear. And the manual too:

http://www-01.ibm.com/support/knowledgecenter/SSGU8G_12.1.0/com.ibm.sqls.doc/ids_sqs_0768.htm?lang=en

As a security measure or not, EXECUTE IMMEDIATE and PREPARE, inside stored procedures don't allow the execution of more than one instruction. A reason for that can be to avoid this specific type of SQL injection exploitation. So it was a good surprise to see that the good people in R&D have thought about something that I failed to (at my first attempt). This is a good security measure. But don't get too enthusiastic.... Terminating a statement and including another on in a variable or argument is just one of the SQL injection attacks. It will be useless on the two examples above. So be aware and never do the same error I was about to do: Always check your parameters and if possible PREPARE your statements. That's the way to avoid these security issues.
For the so called "cursory" statements we can use PREPARE, DECLARE, OPEN, FETCH, CLOSE and FREE. For non-cursory statements we need to use EXECUTE IMMEDIATE. In any case, it's essential to validate all inputs!





Versão Portuguesa
Recentemente foi-me pedido que implementasse algumas stored procedures num cliente. O pedido era urgente e devo admitir que não prestei a devida atenção. Os procedimentos necessitavam de aceitar alguns valores que seriam depois usados em instruções SQL. As boas práticas mais simples ditam que temos sempre de validar os inputs e sempre que possível usar prepared statements. Estes princípios permitem uma melhor interação com a camada que executa os procedimentos (ou genericamente funções), e mais importante, ajudam-nos a evitar uma falha de segurança bastante má, chamada SQL injection.
A ideia base do SQL injection é terrivelmente simples mas eficiente: Fornecendo argumentos "construidos", exploramos falhas dos programadores que não validam nem purificam os argumentos que lhes são passados, usando-os cegamente na construção de instruções SQL. Ao fazê-lo podemos alterar o sentido dessas instruções e eventualmente até terminá-las e escrevendo outras imediatamente a seguir. Um par de exemplos:
  1. Uma página de autenticação usa a seguinte instrução:
    SELECT
        COUNT(*)
    FROM
        tabela_utilizadores
    WHERE
        nome_utilizador = $USER AND pass_utilizador = '$PASS'
    

    e fonecemos estes argumentos:
    'john_doe'
    'dummy'' OR ( nome_utilizador = ''john_doe'' )'
    

  2. Uma aplicação de banco online utiliza esta instrução SQL:
    UPDATE
        tabela_contas
    SET
        saldo = saldo - $VALUE
    WHERE
        numero_conta = $UM_NUMERO
    

    e fornecemos estes argumentos:
    - 1000
    our_account_number
    

Bom, depois de ter criado os procedimentos, e após alguns testes básicos de funcionalidade, tive um pouco mais de tempo para examinar o código e verifiquei que estava a usar a instrução "EXECUTE IMMEDIATE...", e estava apenas a concatenar um pedaço de SQL com os argumentos fornecidos. Alguns tinham algum tipo de validação muito básica, mas outros não eram validados de todo. Fiquei alarmado e envergonhado com algum daquele código e decidi provar a mim mesmo que aquilo não prestava.... Tentei enviar parâmetros compostos de forma específica, incluind um ";" e uma instrução completa em seguida. A título de exemplo considere algo como:

CREATE PROCEDURE test_proc(table_name VARCHAR(20))
    EXECUTE IMMEDIATE "DROP TABLE " || table_name
END PROCEDURE;
E tentei usar como argumento "tabela_teste;DROP DATABASE d"

(considere que "tabela_teste" era o nome de uma tabela existente e que "d" era o nome de uma base de dados também existente)
Obtive um erro:

26058: EXECUTE IMMEDIATE and PREPARE in SPL cannot allow multiple SQL statements
Isto foi um pouco surpreendente. Tentei outras variações e todas falharam.
A descrição do erro parecia clara. E o manual também:

http://www-01.ibm.com/support/knowledgecenter/SSGU8G_12.1.0/com.ibm.sqls.doc/ids_sqs_0768.htm?lang=en

Por medida de segurança ou não, o EXECUTE IMMEDIATE e o PREPARE dentro de procedimentos SPL não permitem a execução de mais que uma instrução. Uma razão para tal pode ser evitar este tipo específico de exploração de SQL injection. A ser assim foi uma surpresa agradável que o pessoal de I&D se tenha lembrado de algo que eu me esqueci (na primeira versão). Isto constitui uma boa medida de segurança. Mas não fique demasiado entusiasmado.... Terminar uma instrução e incluir outra é apenas uma das variantes do SQL injection. É inútil nos dois exemplos acima. Portanto esteja atento e nunca cometa o mesmo erro que estive á beira de cometer: verifique sempre os parâmetros e se possível utilize o PREPARE das suas instruções SQL. Essa é ainda a melhor forma de evitar estes problemas.
Para as instruções baseadas em cursores podemos usar o PREPARE, DECLARE, OPEN, FETCH, CLOSE e FREE. Para instruções que não retornem um conjunto de resultados necessitamos de usar o EXECUTE IMMEDIATE. Em qualquer caso é essencial validar todos os inputs!

Monday, April 21, 2014

Informix on Power 7 / Informix em Power 7

This article is written in Englsih and Portuguese (original version here)
Este artigo está escrito em Inglês e Português (versão original aqui)


English version
IBM has the capability to do things right without anyone knowing about it. A very simple example of this is the publication of a white paper about the use of Informix on Power7 architecture.
I was aware of the existence of such a document internally, but I didn't noticed it was published.

You can find it and download it easily (doesn't happen always :) ) here:

https://www.ibm.com/developerworks/community/wikis/home?lang=en-us#!/wiki/W6461741bf7e8_47d7_89fc_a0a9233f3ca9/page/IBM%20Informix%20on%20POWER7

The topics covered include:

  • SMT configurations (SMT1, SMT2, SMT4)
  • Dedicated LPAR vs Shared LPAR
  • Virtual Server I/O (VIOS)
  • Memory
  • I/O subsystem
  • Network
  • CPUs
I would like to see something equivalent for virtualization technologies, specifically VMWare.

Versão Portuguesa
A IBM tem a capacidade de fazer coisas boas sem que ninguém saiba. Um exemplo muito simples disto é a publicação de um documento sobre a utilização de Informix em Power 7.
Tinha conhecimento da existência deste documento internamente, mas não dei porque tivesse sido publicado.

Pode encontrá-lo e obtê-lo facilmente (nem sempre isso acontece :) ) aqui:

https://www.ibm.com/developerworks/community/wikis/home?lang=en-us#!/wiki/W6461741bf7e8_47d7_89fc_a0a9233f3ca9/page/IBM%20Informix%20on%20POWER7

Os tópicos abordados inclúem:
  • Configuração de SMT (SMT1, SMT2, SMT4)
  • LPARs dedicadas vs partilhadas
  • Virtual Server I/O (VIOS)
  • Memória
  • Sub-sistema I/O
  • Rede
  • CPUs
Gostaria de ver algo equivalente para plataformas de virtualização, em particular VMWare

Monday, April 14, 2014

IBM Knowledge Center

This article is written in Englsih and Portuguese (original version here)
Este artigo está escrito em Inglês e Português (versão original aqui)


English version
IBM already announced this, at least on this post from the IBM Technical Content blog, but I think it's appropriate to mention it here. The traditional Infocenters, which are the standard IBM documentation online sites, will be discontinued in a near future.
IBM  has replaced all the InfoCenters (one for each product/version) by a centralized site that contains all the documentation for all product/versions. This new site is the IBM Knowledge Center.

What does it mean for us, the users? Not much... it means we'll have to update our links, or better saying, changing several links into just one where we can easily browse the product/versions.
But the new site tries to improve on something that was already introduced into the Infocenters: It will adapt to you and to your needs provided you "login" to the site with your ibm.com user credentials.
IBM Knowledge Center will allow you to:

  • search more effectively
  • create your own bookmarks
  • share the content through email or social networks
  • export content in PDF format
  • add comments
  • provide feedback to IBM
Naturally it's expected this will also bring benefits to IBM. These may include:
  • Having all Infocenters in a single interface brings simplicity and easier management
  • The benefits of introducing a functionality will be available to all products/versions
  • Better customer interaction
 But these will probably reflect into an improvement of customer experience while using the online documentation.
The date for retirement of the Infocenters is yet to be announced, but I urge you to addopt Knownledge Center. You'll notice it works faster than Infocenters and after the initial adaptation period (to get used to the slightly different interface) you'll notice it's better than the previous interfaces. For detailed information, please check the Chat with the Labs webcast about this topic, available at:

https://www.ibm.com/developerworks/community/wikis/home?lang=en_US#!/wiki/Informix+Chat+With+the+Lab/page/Welcome


Versão Portuguesa
A IBM já anunciou isto, pelo menos neste artigo do blog IBM Technical Content, mas penso que é apropriado referi-lo também aqui. Os tradicionais Infocenters, que são os sites de documentação online serão descontinuados num futuro próximo.
A IBM substitui-o todos os Infocenters (um para cada versão de cada produto) por um sitio centralizado que contém toda a documentação de todos os produtos e versões. O novo site é o IBM Knowledge Center.

O que é que isto significa para todos nós, utilizadores? Não muito.... Significa que teremos de atualizar os nossos links, ou dizendo melhor, mudar vários links para um único onde podemos facilmente percorrer as várias versões dos produtos. Mas o novo site tenta melhorar algo que já tinha sido introduzido nos Infocenters: Tenta adaptar-se a si e às suas necessidades, desde que se autentique com as suas credenciais de ibm.com.
O IBM Knowledge Center permite-lhe:
  • Efetuar pesquisas de forma mais eficaz
  • Criar os seus próprios marcadores ou apontadores para zonas da documentação
  • Partilhar os conteúdos por emaili e/ou redes sociais
  • Exportar os conteúdos em PDF
  • Adicionar comentários
  • Dar feedback à IBM
Naturalmente, também se espera que a IBM tire benefícios desta mudança. Entre os quais:
  • Ter todos os Infocenters numa única interface traduz-se em simplicidade e gestão mais eficiente
  • Os benefícios de introduzir uma nova funcionalidade ficarão disponíveis para todos os produtos e versões
  • Uma melhor interação com os clientes
Mas estas melhorias do lado da IBM acabam por se traduzir numa melhor experiência para o cliente durante a utilização da documentação online
A data para se descontinuar os InfoCenters ainda não está definida (tanto quanto julgo saber), mas sugiro que adopte desde já o Knowledge Center.. Verá que funciona mais rápido que os Infocenters e logo após a adaptação inicial, verá que é melhor que a interface antiga. Para mais detalhes, por favor consulte o webcast sobre este tema disponível na página dos Chat With the Labs, no seguinte endereço::

https://www.ibm.com/developerworks/community/wikis/home?lang=en_US#!/wiki/Informix+Chat+With+the+Lab/page/Welcome






Heart bleed bug

This article is written in Englsih and Portuguese (original version here)
Este artigo está escrito em Inglês e Português (versão original aqui)



English version
If you have the slightest security concern, you've certainly noticed that everybody is very concerned with a security issue found on OpenSSL which was named Heart Bleed bug (a kind of joke because the bug attacks a functionality of SSL/TLS known as the Hearbeet extension). And this is perfectly justifiable. This has been considered one of the most serious security threat of the latest years. Why? Because it can be used to steal cryptographic sensitive information from sites like private keys. With these information the attackers can do all sorts of things, specifically impersonating those sites, and after that they can steal user information, passwords etc. The issue per si, is terrible, but the worst is that OpenSSL is used by many products, which means that this is not "just" a vendor specific bug.
Given the wide impact and seriousness of this issue most vendors hurried up to make sure if their products were affected or not by the bug. The OpenSSL versions affected by this bug are between 1.0.1 and 1.0.1f. Previous versions are safe (because they didn't implement the specific extension) and 1.0.1g includes the fix. So the question translate into: Do we use OpenSSL? And if yes, do we use an unsafe version?
In the immediate days after the public disclosure of this bug we received several questions from customers inquiring if our products were safe or not. And IBM hurried up to create alerts and information about this.
The relevant links are:


So, the good news is that Informix is safe from this bug. The SSL/TLS functionality used by Informix is provided by the generic IBM Global Security Kit which is not affected by the Heart Bleed bug




Versão Portuguesa
Se tem algum tipo de preocupação com a segurança, então certamente reparou que anda toda a gente preocupada com um problema de segurança descoberto no OpesSSL que recebeu o nome de Heart Bleed bug (uma piada ao facto de a falha estar na implementação de uma funcionalidade do SSL/TLS conhecida como extensão Heart Beet). E todo este alarme é perfeitamente compreensível e justificável. Este problema foi considerado como um dos mais sérios problemas de segurança descobertos nos últimos anos. Porquê? Porque pode ser usado para obtenção ilícita de informação sensível de criptografia, nomeadamente chaves privadas. Com esta informação os atacantes podem fazer uma série de coisas, entre as quais apresentarem-se como os sites legítimos e a partir daí obter informação sensível dos utilizadores como as suas palavras-chave. O assunto por si só já é terrível, mas o pior é que o OpenSSL é usado em muitos produtos de software, o que faz com que isto não esteja limitado a um fornecedor e/ou produto.
Dado o impacto alargado e a gravidade da falhar, a maioria dos vendedores apressaram-se a verificar se os seus produtos estariam afetados pelo problema. As versões do OpenSSL afetadas são as 1.0.1 até à 1.0.1.f. As versões anteriores não são afetadas pois não implementavam a extensão em causa, e a 1.0.1g incluí a correção para o problema. Portanto a questão resume-se a: Usamos OpenSSL? Se sim, usamos uma versão afetada?
Nos dias imediatamente a seguir aos anúncios públicos desta falha, recebemos várias questões de clientes a interrogarem-se se os nossos produtos estavam a salvo ou não deste bug. E a IBM apressou-se a criar alertas com informação sobre o tema. Os endereços relevantes para se entender o tema são:

Portanto, as boas notícias é que o Informix está a salvo desta falha de segurança. A funcionalidade SSL/TLS usada pelo Informix é fornecida pelo IBM  Global Security Kit, que não foi afetado pelo bug Heart Bleed.

Monday, April 07, 2014

50(!) years of IBM Mainframe / 50(!) anos do Mainframe da IBM

This article is written in English and Portuguese (original version here)
Este artigo está escrito em Inglês e Português (versão original aqui)



English version:

You know that I rarely (if ever) post any information that does not relate to Informix here. In particular I don't use the blog to promote IBM or IBM products. But I believe this event is above all that. I'm not sure if anyone can define the birth date of a system (do you consider the first announcement, the start of the project, the first sale...?), but officially IBM Mainframe turns 50 today.
That's half a century... I'd say it's impossible to find another system that can match that (age) and that is still alive... I'm sure that the vast majority of my readers never worked with/in a mainframe. But I'd bet all of you have used a service based on a Mainframe today. We tend to think it belongs to an ancient world, where no innovation takes place etc. But, although I'm totally ignorant in regards to that environment one thing I can assure you: Many, or nearly most of the things we use today in LUW came from the mainframe. And if you think that was the case, but not anymore, let me just remind you that the first implementation of the blink project was on the mainframe. Today you can use it in Informix's Warehouse Accelerator and IBM DB2 Blu. If they keep the pace, I'm sure that what we'll use tomorrow is being developed there today. Just for fun, you may want to check tomorrow's live event about the next 50 years of the Mainframe.
And to close this in a way that's not offtopic, I can also remind you that Informix runs on zLinux :)


Versão Portuguesa:

É sabido que eu raramente (se é que aconteceu) escrevo aqui alguma coisa que não esteja relacionado com o Informix. Não uso o blog para promover a IBM ou outros produtos da IBM. Mas acredito que este evento está acima de tudo isso. Não sei se será possível a alguém definir a data de nascimento de um sistema (considera-se o primeiro anúncio, o início do projeto, a primeira venda...?), mas oficialmente o Mainframe da IBM faz 50 anos hoje.
É meio século... Diria que é impossível encontrar outro sistema com esta idade e que esteja ainda vivo... Apostaria que a maioria dos meus leitores nunca trabalharam com ou num Mainframe. Mas tenho a certeza que todos usaram um serviço baseado em Mainframe hoje. Temos tendência para pensar que o Mainframe pertence a um mundo antigo, onde não existe inovação etc. Mas apesar de ser totalmente ignorante sobre este ambiente há algo que posso assegurar: Muitas das coisas que usamos hoje em LUW (Linux/Unix/Windows) vieram do Mainframe. E se pensa o contrário, ou que tal já não acontece basta relembrar que a primeira implementação do projecto blink foi no Mainframe. Hoje pode usá-lo no Informix Warehouse Accelerator e no IBM DB2 Blu.
Se mantiverem o ritmo certamente o que usaremos amanhã é o que está lá a ser implementado hoje.
Para saber mais, nem que seja por curiosidade, poderá assistir amanhã a um evento na web sobre os próximos 50 anos do Mainframe.
E para encerrar o artigo de forma não off-topic, posso relembrar que o Informix corre em zLinux :)