análisis de código estático para detectar pasando un wchar_t * a BSTR

Question

Desde un BSTR es sólo una typedef para wchar_t* nuestra base de código tiene varios (muchos?) Los lugares donde se pasan los literales de cadena a un método esperando un desastre BSTR esta lata con señaleros o cualquiera que intente utilizar cualquier método específico BSTR (por ejemplo, SysStringLen).

¿Hay alguna forma de detectar estáticamente este tipo de uso indebido?

he intentado compilar con VC10 /Wall y con el análisis de código estático Microsoft Todas las reglas pero el siguiente fragmento de código que no quede marcado por uno de ellos.

void foo(BSTR str) 
{ 
    std::cout << SysStringLen(str) << std::endl; 
} 

int _tmain() 
{ 
    foo(L"Don't do that"); 
} 

---

Actualización: Después de tratar de destrozar wtypes.h en la detección de este tipo de transgresiones que he dado por vencido.

Intenté dos rutas, ambas de las cuales comencé a trabajar con mi programa de ejemplo anterior, pero una vez que probé un proyecto real fallaron.

1. crear una clase llamada BSTR pero desde un VARIANT tiene un BSTR como un miembro de un sindicato de la nueva clase no podían tener ningún constructor o los operadores de asignación Esto rompió todos los lugares se NULL fue tratado como un BSTR. Traté de reemplazar NULL con un tipo que tiene operadores de conversión pero después de agregar docenas de nuevos operadores (comparación, conversión, etc.) comencé a encontrarme con llamadas ambiguas y desistí.
2. Probé de la manera sugerida por @CashCow y @Hans (haciendo BSTR a typedef a otro tipo de puntero). Eso tampoco funcionó, después de agregar los métodos toBSTR y fromBSTR y tirar basura comutil.h (_bstr_t) y otros lugares con conversiones finalmente llegué al punto en que el compilador se atascó en los encabezados producidos a partir de IDL (los valores predeterminados se traducen al literal cuerdas anchas).

En resumen, he dejado de tratar de lograr esto por mi cuenta, si alguien sabe de una herramienta de análisis de código que pueda ayudar, estaría encantado de saberlo.

Answer 1

Creo que Coverity afirma que detecta este tipo de vulnerabilidades. Recuerdo que mencionaron cosas de COM específicamente cuando demostraron a una empresa para la que trabajaba.

Su datasheet ciertamente parece implicar que verifican las clases de uso incorrecto de BSTR. Tienen un período de demostración; podrías intentarlo y ver si marca tu entrada de muestra.

Answer 2

¿Puede cambiar sus métodos para tomar _bstr_t o CComBSTR en su lugar?

Si no, entonces como un literal es técnicamente un const wchar_t *, si hay una configuración del compilador para no permitir la conversión del puntero literal-> no const, entonces puede hacerlo.

De lo contrario, existe la posibilidad de modificar la definición de BSTR para que sea unsigned short *. Entonces, si construyes toda tu fuente, obtendrás errores de compilación siempre que se transmita un literal y podrás corregir todo este código. Entonces sugeriría que lo cambie de nuevo ...

Answer 3

Sobrecargue todas las funciones con el BSTR y reenvíelas con la conversión adecuada.

void foo(BSTR str) 
{ 
    std::cout << SysStringLen(str) << std::endl; 
} 

void foo(const WCHAR *str) 
{ 
    foo(SysAllocString(str)); 
} 

int _tmain() 
{ 
    foo(L"don't do this"); 
    return 0; 
} 

O, para generar errores de compilación, cambiar todos los tipos de parámetros de BSTR a otra cosa y buscar los errores:

typedef UINT bar; 

void foo(bar _str) 
{ 
    // make the compiler happy below 
    BSTR str = (BSTR)_str; 
    std::cout << SysStringLen(str) << std::endl; 
} 

int _tmain() 
{ 
    foo(L"don't do this"); 
    foo((bar)42); 
    return 0; 
} 

error C2664: 'foo': No se puede convertir el parámetro 1 de 'const wchar_t [14]' a 'bar'

Supongo que el error C2664 y el tipo 'const wchar_t []' identificado por el compilador es lo que quiere que el compilador encuentre para cada llamada interna realizada al función usando el BSTR?

Answer 4

Puede intentar compilar con Clang, su análisis estático/dinámico puede encontrar lo que está buscando.